+++ This bug was initially created as a clone of Bug #198623 +++
The "sudo" program can operate in "login" mode with the "-i" parameter. In
this respect it is like "su - [user]" and should force a new keyring; in other
situations it should not (as for "su [user]").
WHAT NEEDS TO BE DONE
The PAM scripts for the login programs need to be altered to forcibly create a
new session keyring when a login event occurs.
These simply require the following line adding to their PAM scripts:
session optional pam_keyinit.so force revoke
This forces them to create a new session keyring during login, replacing the
one inherited from their parent, and causes the session keyring so created to
be revoked when the login process exits.
Ideally, this should be "required" not "optional", but it still has to work if
the pam_keyinit.so library is absent.
The authlogin program needs modifying to add:
session optional pam_keyinit.so revoke
To the default session (system-auth). This just creates a new session keyring
if one doesn't yet exist for this process.
The "su" program needs to split its "su - [user]" mode PAM script from its "su
[user]" PAM script, so that the former can forcibly create a keyring whilst
the latter doesn't.
-- Additional comment from firstname.lastname@example.org on 2006-07-12 10:00 EST --
The keyring in question is the session keyring maintained by the kernel for
each process and manageable through the keyutils package.
-- Additional comment from email@example.com on 2006-07-12 10:24 EST --
/usr/sbin/in.telnetd uses /bin/login
$ rpm -qf /bin/login
Created attachment 132361 [details]
Separate out PAM script for "sudo -i" and add keyinit instructions to samples
Patch to make sudo use separate PAM scripts for "sudo" and "sudo -i". Also
creates a new sample PAM script for "sudo -i" and adds appropriate keyinit
instructions to both.
Created attachment 132362 [details]
Modify SPEC file to add keyring initialisation to PAM scripts
David, I think your solution based on def_env_reset is not the best idea,
because it could be enabled by the "Default env_reset" option in sudoers. I want
to be sure, so I've rather used:
+ if (ISSET(sudo_mode, MODE_LOGIN_SHELL))
+ pam_status = pam_start("sudo-i", pw->pw_name, &pam_conv, &pamh);
+ pam_status = pam_start("sudo", pw->pw_name, &pam_conv, &pamh);
and added HAVE_PAM_LOGIN to configure.in. I think it's a way which could be
accepted by upstream (I hope:-).
Thanks for your work.
Karel - are your concerns regarding David's proposed approach, and subsequent
alternative implementation, applicable to the numerous other login type
utilities? I ask this question because there are about 10 packages with the
same fix suggested. So I'm not sure if the other packages are ok as-is or
whether they should consider your alternative approach.
Tim, this thing (in comment #4) is sudo specific and doesn't have impact to the
For login processes (= create new session) we need "force revoke" and for the
rest we need "revoke" in PAM setting. The sudo command is specific, because it
supports both modes. So, we need a way how do distinction between this modes in
sudo code. My concern was about the way how David has done this distinction.