[OpenAFS] PAM problem with 1.4.4 and Linux

Simon Wilkinson sxw@inf.ed.ac.uk
Fri, 25 Jan 2008 17:11:14 +0000

Hash: SHA1

On 25 Jan 2008, at 16:54, Jeff Blaine wrote:

> I do have to admit though that I have no idea what "keyring
> based PAGs" means.

AFS typically provides session based PAGs. These allow you to  
seperate your AFS credentials into compartments that are based on a  
session identifier, rather than the UID (so, for instance, two  
processes both running as root may have different sets of AFS  
credentials). This requires that each 'session' have a unique  
identifier associated with it, that's unchangeable by the user and,  
ideally, that persists across changes in UID. Historically, this  
identifier was used by adding the user to two unused groups, whose  
IDs, when combined together would produce the unique number that  
identified that session (or PAG). The user would be added to these  
groups when setpag() was called, and a hook to the kernel's initgroups 
() command would ensure that the groups were copied across UID  
changes. In recent releases the two group IDs have been replaced by a  
single 32 bit group ID, but the rest of the principle is the same.

However, Linux is making it increasingly hard for kernel modules to  
play in this way. The initgroup() hook, in particular, relied on  
finding and patching kernel internals, which are no longer modifiable  
on many kernel builds (exactly what is and isn't possible depends not  
on kernel version, but on a multitude of kernel build time options).  
So, an alternative mechanism is used on these kernels.

This alternative mechanism relies on the 'keyring' feature present in  
recent Linux kernels. Keyrings provide a mechanism for associating  
arbitrary information securely with UIDs, processes, or (critically)  
sessions. This can be used for things like kernel credential caches,  
X509 key material, and the like. AFS uses it to hold the PAG  
identifier in a session keyring. This implements the session-based  
PAG behaviour, without requiring the same kernel hackery as the group  
code (it has the added advantage that users don't see random groups  
appearing when they view their group list)

The critical part of the pam_keyinit code is that it clears out the  
current keyring for an incoming user. Session based keyrings suffer  
from the same dangers as PAGs - if the daemon which authenticates the  
user (sshd, for example) has a session keyring, then shells spawned  
by that daemon may inherit those keys. If those keys are ones that  
are private to root, this will probably cause problems!

Hope that helps,


Version: GnuPG v1.4.7 (Darwin)