Bug 198755 - Make login processes initialise session keyring
Summary: Make login processes initialise session keyring
Alias: None
Product: Fedora
Classification: Fedora
Component: sudo
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Ben Levenson
Keywords: Reopened
Depends On:
Blocks: 198623
TreeView+ depends on / blocked
Reported: 2006-07-13 10:01 UTC by David Howells
Modified: 2007-11-30 22:11 UTC (History)
0 users

Clone Of:
Last Closed: 2006-07-16 22:37:26 UTC

Attachments (Terms of Use)
Separate out PAM script for "sudo -i" and add keyinit instructions to samples (3.03 KB, patch)
2006-07-13 10:56 UTC, David Howells
no flags Details | Diff
Modify SPEC file to add keyring initialisation to PAM scripts (1.76 KB, patch)
2006-07-13 11:01 UTC, David Howells
no flags Details | Diff

Description David Howells 2006-07-13 10:01:37 UTC
+++ 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]").

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 dhowells@redhat.com 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 harald@redhat.com on 2006-07-12 10:24 EST --
/usr/sbin/in.telnetd uses /bin/login
$ rpm -qf /bin/login

Comment 1 David Howells 2006-07-13 10:56:19 UTC
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.

Comment 2 David Howells 2006-07-13 11:01:15 UTC
Created attachment 132362 [details]
Modify SPEC file to add keyring initialisation to PAM scripts

Comment 4 Karel Zak 2006-07-16 22:37:26 UTC
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);
+    else
+           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.

Comment 5 Tim Burke 2006-07-19 11:41:09 UTC
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.

Comment 6 Karel Zak 2006-07-19 12:10:53 UTC
Tim, this thing (in comment #4) is sudo specific and doesn't have impact to the
others packages. 

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.

Note You need to log in before you can comment on or make changes to this bug.