Hello there!
Till now the default ccache location has been: DEFCCNAME=DIR:/run/user/%%{uid}/krb5cc
Kerberos has added support for kernel keyring support for quite a while, so now it is a good opportunity to consider moving default ccache location to kernel keyring instead, which brings several advantages: - Avoiding involving the file system to reduce potential surface of attack. - Using kerberos utilities while in another user's shell (acquired by su or sudo) will no longer throw "credentials cache not found" error.
The move is unlikely to cause compatibility issues between Kerberos and identity management solutions such as SSSD and Winbind. SSSD reads the ccache location settings from kerberos and will adapt to the change automatically. Winbind supports keyring-type ccache and goes even further to commend it being "the most secure and predictable method".
However, the following components require more thorough testing and/or additional patches to be made: - YaST windows domain membership module The module generates configuration files for file-based ccache, could it generate configurations that use kernel keyring instead? - SSH, NFS utilities, mod-auth-kerb I am not yet sure whether these components can also make use of kernel keyring, need more investigation.
Apart from those components above, are there other things I am missing?
Comments and suggestions are welcome.
Regards, Howard
Hello,
Am Donnerstag, 14. Januar 2016 schrieb Howard Guo:
Till now the default ccache location has been: DEFCCNAME=DIR:/run/user/%%{uid}/krb5cc
At least for winbindd, I tend to disagree (winbindd probably overrides the location). According to the AppArmor profile, we have
2328 apparmo | /tmp/krb5cc_* rwk,
- updates for samba 4.x and kerberos (bnc#846586#c12 and #c15, bnc#845867, bnc#846054)
2461 apparmo | /var/cache/krb5rcache/* rw,
- allow rw access to /var/cache/krb5rcache/* (bnc#870607)
Kerberos has added support for kernel keyring support for quite a while, so now it is a good opportunity to consider moving default ccache location to kernel keyring instead, which brings several advantages: - Avoiding involving the file system to reduce potential surface of attack. - Using kerberos utilities while in another user's shell (acquired by su or sudo) will no longer throw "credentials cache not found" error.
The move is unlikely to cause compatibility issues between Kerberos and identity management solutions such as SSSD and Winbind. SSSD reads the ccache location settings from kerberos and will adapt to the change automatically. Winbind supports keyring-type ccache and goes even further to commend it being "the most secure and predictable method".
Apart from those components above, are there other things I am missing?
Please check if winbind still works with AppArmor enabled after changing to the kernel keyring. (In other words: does using the kernel keyring need access to something in /proc/, /sys/ or /dev/?)
I don't know or use Kerberos (actually I don't even use Samba anymore, but at least know it a bit), therefore I can't test myself.
A similar question applies for dovecot, which can also use Kerberos. For more details, see the usr.lib.dovecot.auth AppArmor profile and https://bugzilla.novell.com/show_bug.cgi?id=851984
Some testing if Dovecot (with Kerberos configured) still works when using the kernel keyring would be welcome ;-)
Regards,
Christian Boltz
Appreciate your input Christian.
Kernel keyring does not touch file system at all, so in this case the AppArmor profiles can be simplified. I just wrote in my check list to remember to test dovecot.
Regards, Howard
On Thu, 14 Jan 2016, Christian Boltz wrote:
At least for winbindd, I tend to disagree (winbindd probably overrides the location). According to the AppArmor profile, we have
2328 apparmo | /tmp/krb5cc_* rwk,
- updates for samba 4.x and kerberos (bnc#846586#c12 and #c15, bnc#845867, bnc#846054)
2461 apparmo | /var/cache/krb5rcache/* rw,
- allow rw access to /var/cache/krb5rcache/* (bnc#870607)
Please check if winbind still works with AppArmor enabled after changing to the kernel keyring. (In other words: does using the kernel keyring need access to something in /proc/, /sys/ or /dev/?)
I don't know or use Kerberos (actually I don't even use Samba anymore, but at least know it a bit), therefore I can't test myself.
A similar question applies for dovecot, which can also use Kerberos. For more details, see the usr.lib.dovecot.auth AppArmor profile and https://bugzilla.novell.com/show_bug.cgi?id=851984
Some testing if Dovecot (with Kerberos configured) still works when using the kernel keyring would be welcome ;-)
Hi Howard,
On Thu, Jan 14, 2016 at 11:45:28AM +0100, Howard Guo wrote: [ 8< ]
- YaST windows domain membership module
The module generates configuration files for file-based ccache, could it generate configurations that use kernel keyring instead?
It should as the CONFIG_PERSISTENT_KEYRINGS=y is set since openSUSE 13.2 at the kernel config level.
First I thought it would be nice to offer the opportunity to select between FILE, DIR, and KEYRING. But the latter is as you wrote the most secure and also most easy to handle approach.
Therefore on the YaST level I would simply add a check if CONFIG_PERSISTENT_KEYRINGS=y and then make use of the keyring and otherwise our old FILE base approach.
No extra questions and tweaking. All we do is to log that we found CONFIG_PERSISTENT_KEYRINGS=y and are making use of the keyring.
Do we have a bug to track thic issue yet?
I don't like to abuse 899118
Cheers,
Lars
On Thu, Jan 14, 2016 at 11:23 AM, Lars Müller lmuelle@suse.com wrote:
Therefore on the YaST level I would simply add a check if CONFIG_PERSISTENT_KEYRINGS=y and then make use of the keyring and otherwise our old FILE base approach.
No Lars, that's going to break more sooner than later. the naming of kernel config options are not part of any ABI/API promise and change pretty frequently..
On Thu, Jan 14, 2016 at 12:48:32PM -0300, Cristian Rodríguez wrote:
On Thu, Jan 14, 2016 at 11:23 AM, Lars Müller lmuelle@suse.com wrote:
Therefore on the YaST level I would simply add a check if CONFIG_PERSISTENT_KEYRINGS=y and then make use of the keyring and otherwise our old FILE base approach.
No Lars, that's going to break more sooner than later. the naming of kernel config options are not part of any ABI/API promise and change pretty frequently..
Do they really?
If there is no reliable way to ckeck if the keyring feature is available, then we'll do it much simpler and enable it depending on the openSUSE code stream/ version.
This would only cause a very small potential issue to those users running newer kernels on older releases.
Cheers,
Lars
Hi Lars,
On 14.01.2016 17:19, Lars Müller wrote:
If there is no reliable way to ckeck if the keyring feature is available, then we'll do it much simpler and enable it depending on the openSUSE code stream/ version.
This would only cause a very small potential issue to those users running newer kernels on older releases.
No, actually it would not cause problems at all: users running new kernels on old releases would just not use the new feature and instead still use the file backend.
And running old kernels on newer releases is not guaranteed to work anyway (you can't run SLES12 userspace on SLES11SP1 kernel, for example :-P)
Have fun,
seife
-
Christian Boltz -
Cristian Rodríguez -
Howard Guo -
Lars Müller -
Stefan Seyfried