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 --

(gnome packages are getting too few and too easy :P ) Be sure that I'll keep this quote for later when we'll suffer some pain with gnome packages ;-) [> Dominique Leuenberger and Vincent Untz in opensuse-factory]

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

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 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 -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany