[OpenAFS] PAM problem with 1.4.4 and Linux
Simon Wilkinson
sxw@inf.ed.ac.uk
Fri, 25 Jan 2008 17:11:14 +0000
-----BEGIN PGP SIGNED MESSAGE-----
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,
Simon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
iD8DBQFHmhgyqWndc26pXmcRAr9qAKCEpAJinX6u7aBC8tlwYDSfr1kfMACgo9Zq
Vg9ncnkyUr/QK+6VRsGO2ok=
=P4Cy
-----END PGP SIGNATURE-----