[OpenAFS-devel] Simplified integration of OpenAFS, Kerberos SSH and PAM (again)

[Tom Keiser]

On 5/11/05, Russ Allbery <rra@stanford.edu> wrote:
> Douglas E Engert <deengert@anl.gov> writes:
>=20
> > aklog -setpag is another problem, as a child being able to change the
> > parent process is sort of against unix basic principals. I don't think
> > this works on all systems either.
>=20
> Right, I agree.  I think that newer kernel models are going to make this
> difficult to maintain.  This is just what libpam-openafs-session is doing
> right now because it's what worked without requiring libraries not
> suitable for linking to a PAM module.
>=20

Yeah.  I think setpag() should be made to have similar semantics to setsid(=
).

>=20
> The idea is that your aklog implementation would then use this routine to
> push the token into the kernel, after it's done whatever it has to do in
> Kerberos terms to get the thing ready.  And the library that provided thi=
s
> routine and the setpag routine would basically be the "AFS system call
> library" with no dependencies on any other libraries at all.  It's job
> would just be to expose the system calls that userspace programs that
> aren't AFS programs need to use as functions with a highly stable ABI.
>=20

One quick point, do we need to worry about issues related to the
future move away from the 1:1 cell to key mapping?  As long as the
library API treats the creds as opaque, I guess this isn't an issue.

> > Another way to do this is to ask the AFS Kernel modules to have a helpe=
r
> > process to get tokens using the ticket cache. If AFS every wants to hav=
e
> > different principals for different AFS servers, it will need something
> > like this.
>=20
> Personally, I think it's more likely that the trend will go the other
> direction and people are going to start wanting to put Kerberos ticket
> caches in the kernel the way tokens are now.  I could be wrong, but the
> kernel call back down into user space to try to find the user's ticket
> cache seems fraught with danger to me.  The kernel is actually better
> positioned to keep ticket caches attached to the right processes and make
> sure that only authorized processes can get at them.
>=20

I'm a fan of making AFS act more like a traditional K5 service, so I
like Doug's idea of automated cred acquisition using the ticket cache.
 Frankly, I hope the next-generation security architecture eliminates
any need for credential translators like aklog.  In a multi-key cell
it's not going to be efficient for something like aklog to do TGS reqs
for the service principal of every fileserver (or fileserver group).=20
Since many PAGs will end up making conns to only a small subset of the
fileservers in a cell, I think TGS reqs should happen on an as-needed
basis.  The downside is this means you either need something similar
to the DCE kernel authn helper daemon and upcall interface, or a
fairly robust in-kernel library to handle GSS, K5 and ASN.1.  It would
be nice if the various NFSv4/rpcsec_gss client projects resulted in
OSs developing generic kernel APIs to address things like service
ticket acquisition, and credential cache management...

If you're right, and vendors start putting the krb5cc in the kernel,
then we might be able to leave credential stuffing up to projects like
pam_krb5.  Then, we could focus our attention on mapping a PAG to a
particular kernel credential cache.

--=20
Tom Keiser
tkeiser@gmail.com