Thanks very much, Simon. I'm sure that was good reading
for people other than just myself. A good one for the
list archives.
Simon Wilkinson wrote:
-----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-----
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
