Bug#734818: enable pam_keyinit by default
Le Wed, 7 May 2014 08:18:09 -0700, Steve Langasek vor...@debian.org a écrit : On Wed, May 07, 2014 at 10:13:02AM +0200, Laurent Bigonville wrote: Le Tue, 6 May 2014 09:36:59 -0700, Steve Langasek vor...@debian.org a écrit : On Tue, May 06, 2014 at 09:12:59AM -0700, Russ Allbery wrote: Laurent Bigonville bi...@debian.org writes: On Fedora they are using: session optional pam_keyinit force revoke force revoke looks good to me. I'm not sure that force is necessary, but it's probably a good idea in general. As it's only available on linux architectures, I was thinking of adding a '-' at the beginning of the call. Do you think this is OK for Debian? Yes, although this is where it would be nice if this could somehow be handled by pam-auth-update so that the PAM module wouldn't be configured at all on systems that don't have it. As discussed on IRC, we don't want this to silently fail on Linux systems because of some unrelated bug; that will just cause difficult-to-diagnose problems. Since the module will be present on all Linux systems, it's better to ship a different pam config on Linux vs. non-Linux architectures, which can be done fairly easily without duplication using dh-exec. And couldn't we use the (dirty) trick we are using for pam_selinux? Which trick are you talking about? pam_selinux is called like this in some pam services to not fail if the module is not existing: session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734818: enable pam_keyinit by default
Le Tue, 6 May 2014 09:36:59 -0700, Steve Langasek vor...@debian.org a écrit : On Tue, May 06, 2014 at 09:12:59AM -0700, Russ Allbery wrote: Laurent Bigonville bi...@debian.org writes: On Fedora they are using: session optional pam_keyinit force revoke force revoke looks good to me. I'm not sure that force is necessary, but it's probably a good idea in general. As it's only available on linux architectures, I was thinking of adding a '-' at the beginning of the call. Do you think this is OK for Debian? Yes, although this is where it would be nice if this could somehow be handled by pam-auth-update so that the PAM module wouldn't be configured at all on systems that don't have it. As discussed on IRC, we don't want this to silently fail on Linux systems because of some unrelated bug; that will just cause difficult-to-diagnose problems. Since the module will be present on all Linux systems, it's better to ship a different pam config on Linux vs. non-Linux architectures, which can be done fairly easily without duplication using dh-exec. And couldn't we use the (dirty) trick we are using for pam_selinux? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734818: enable pam_keyinit by default
On Wed, May 07, 2014 at 10:13:02AM +0200, Laurent Bigonville wrote: Le Tue, 6 May 2014 09:36:59 -0700, Steve Langasek vor...@debian.org a écrit : On Tue, May 06, 2014 at 09:12:59AM -0700, Russ Allbery wrote: Laurent Bigonville bi...@debian.org writes: On Fedora they are using: session optional pam_keyinit force revoke force revoke looks good to me. I'm not sure that force is necessary, but it's probably a good idea in general. As it's only available on linux architectures, I was thinking of adding a '-' at the beginning of the call. Do you think this is OK for Debian? Yes, although this is where it would be nice if this could somehow be handled by pam-auth-update so that the PAM module wouldn't be configured at all on systems that don't have it. As discussed on IRC, we don't want this to silently fail on Linux systems because of some unrelated bug; that will just cause difficult-to-diagnose problems. Since the module will be present on all Linux systems, it's better to ship a different pam config on Linux vs. non-Linux architectures, which can be done fairly easily without duplication using dh-exec. And couldn't we use the (dirty) trick we are using for pam_selinux? Which trick are you talking about? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#734818: enable pam_keyinit by default
Hello, Steve Langasek wrote: Hi Russ, On Wed, Jan 08, 2014 at 07:00:54PM -0800, Russ Allbery wrote: It would be better for any application that uses the kernel keyring if pam_keyinit were run by default in the PAM session stack. Without this module, users are placed in a default UID-based user session, which doesn't isolate each session's keys. Worse, currently (although this is a separate bug that's been separately reported and may be fixed in the future), the kernel uses the UID session for reading, but when writing creates a new session keyring that's limited to children of the writing process. This basically makes use of keyring Kerberos caches impossible unless one does the equivalent of what pam_keyinit does first. It's rather inobvious that this is necessary. The problem with this, which will make it more complex, is that one generally does not want to create a new session keyring when running commands like su or sudo, just for login sessions, since you normally want to preserve the user's existing credentials. I'm not sure what this means for how to achieve this configuration. Unfortunately, there's no central way to configure PAM modules only for use in login sessions. As with pam_selinux and pam_loginuid, the only way to do this is for each service to include the module directly in their own PAM config. Do you have an idea on how it should be called? On Fedora they are using: session optional pam_keyinit force revoke As it's only available on linux architectures, I was thinking of adding a '-' at the beginning of the call. Do you think this is OK for Debian? I guess it should be the same in all the initial login pam services. Cheers, Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734818: enable pam_keyinit by default
Laurent Bigonville bi...@debian.org writes: On Fedora they are using: session optional pam_keyinit force revoke force revoke looks good to me. I'm not sure that force is necessary, but it's probably a good idea in general. As it's only available on linux architectures, I was thinking of adding a '-' at the beginning of the call. Do you think this is OK for Debian? Yes, although this is where it would be nice if this could somehow be handled by pam-auth-update so that the PAM module wouldn't be configured at all on systems that don't have it. I guess it should be the same in all the initial login pam services. I think so, yes. Thanks for looking at this! -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734818: enable pam_keyinit by default
On Tue, May 06, 2014 at 09:12:59AM -0700, Russ Allbery wrote: Laurent Bigonville bi...@debian.org writes: On Fedora they are using: session optional pam_keyinit force revoke force revoke looks good to me. I'm not sure that force is necessary, but it's probably a good idea in general. As it's only available on linux architectures, I was thinking of adding a '-' at the beginning of the call. Do you think this is OK for Debian? Yes, although this is where it would be nice if this could somehow be handled by pam-auth-update so that the PAM module wouldn't be configured at all on systems that don't have it. As discussed on IRC, we don't want this to silently fail on Linux systems because of some unrelated bug; that will just cause difficult-to-diagnose problems. Since the module will be present on all Linux systems, it's better to ship a different pam config on Linux vs. non-Linux architectures, which can be done fairly easily without duplication using dh-exec. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
