Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[David Howells <dhowells@warthog.cambridge.redhat.com>]

> My take on this is that I'm personally totally uninterested in AFS and
> Kerberos.

A lot of people though are interested in network filesystems (of which AFS is
but one example) and authenticating them (Kerberos is not unusual for this).

AFS itself doesn't really give a rat's backside about PAGs. They exist solely
within the client's deranged imagination as a means of coordinating sessions
between the kernel and userspace AFAICT and they are also used as a basis for
selecting cached credentials.

> What I _am_ interested in is things like per-user VPN keys, and things
> like keeping my local harddisk encrypted.

Anything that can be used for network fs's (with distributed authority
services) ought to be useful for purely local token management (where the
authority is trivial).

> So myt background is that unless the credentials are useful for something
> like that, then they aren't useful AT ALL.

I concur.

> With a local encryption, what I'm perfectly willing to do is to go through
> a "strong authentication" once, but once I've done that, I don't want to
> do it again every time I log in to that machine.

Are you requiring that the tokens be retained when you fully log out from a
machine?

> I use ssh all the time, and I have a few machines I trust, so when I come in
> from such a trusted machine, and the strong authentication session is
> already in progress, I don't want to see a password or anything like
> that. It should "just work".

I take it you're _not_ talking about transferring tokens from one machine to
another as part of the ssh login.

> And most importantly, it should "just work" _without_ having to have some
> central service have to know about it. I'm a big believer in _not_ having
> deamons that keep track of something and having to connect to them. I'm ok
> with a "ssh-agent", but I absolutely _abhor_ linkages, and if that ssh
> agent has to know about some "super-agent", and that "super-agent" has to
> talk to my "disk-agent", then you have a total disaster on your hands.

So you copy /etc/passwd around by hand every time you change your password
rather than using NIS, YP, Kerberos, SMB or whatever?

OTOH, with a large organisation with lots and lots of computers, by using
something like this a user should be able to log in anywhere, change their
password anywhere, etc without running the sysadmins ragged.

Or am I misunderstanding you? Are you talking about local daemons for keeping
hold of the tickets you've been granted by remote authorities? If that's the
case, then yes, I agree with you, but I haven't suggested such a thing is
necessary. I don't believe Kerberos, for instance, needs such a thing, but I
may be wrong.

> So I think I should be able to write a small PAM agent that automatically
> joins me with the right keys when I log in. This is my requirement. And
> part of that requirement is that my PAM agent should _not_ have to know
> about _other_ agents that may also be adding and removing keys. There
> should be no "linkages" between different key spaces, yet they should be
> able to use the same basic kernel infrastructure to maintain them.

Sort of like login reads /etc/groups to find out which groups you're in and
then calls setgroups() to load them into the kernel?

Actually, what you're describing sounds like it may have a race, but probably
not one that's significant. What happens if two login sessions for the same
user try to happen simultaneously and both immediately see that the default
keyring for that doesn't yet exist?

> And this is where naming becomes important. Because there should be no
> linkages, I think the ad-hoc naming is a bug.  My PAM module shouldn't
> have to ask somebody else what key ID's to use. It knows who I am, it
> should know where to add my keys. And it should be able to add my keys
> _without_ being in the way of somebody else adding keys.

Sounds like keyrings need names and ACLs (at the very least an owner UID).

> And when I add a key in one window, I want that key to be available in the
> other windows that were opened with independent SSH sessions. Again,
> without having to go through some super-agent to figure things out. The
> kernel _is_ the agent, and if we're adding key knowledge, we should do it
> right.

Fair enough... mostly. You still have to be able to prevent it from been added
under some circumstances.

> If I want just _one_ session to get some special powers (let's say that I
> do the equivalent of "su", except I do it by adding the proper credentials
> to my session instead of by changign to root user), then I should be able
> to just do
>
> 	new-session	/* creates a new local keyring at the top of the
> 			   credentials stack */
> 	add-key xxxx	/* adds a new key to the top keyring - and because
> 			   the top keyring now isn't my default one, other
> 			   ssh sessions won't be seeing this key */
>
> but if I do _just_ the
>
> 	add-key xxxx
>
> then I want that key to show up in all my other sessions too, because now
> I'll be adding a key to my "default session". And it also shows up in the
> window where I have even _more_ capabilities - the "new-session" didn't
> drop my old capabilities, it just created a space to hold even more
> (independent) keys.

Hmmm... Do you envision a strict stack? Or a manipulatable sequence? Take a
SUID program for instance, do you want the SUID credentials to override the
pre-exec credentials until discarded (at which point there's no way to
retrieve them)? Or do you envision the following "commands":

 (*) new-session <name> [<ACL>]

     Create a new private keyring or session, potentially with ACL governing
     joining, modification, etc. by users and/or groups.

 (*) list-sessions <name>

     List keyrings available to this process

 (*) list-keys <name>

     List keys in the available session

 (*) upgrade-session <name>

     Move session to front of sequence. Becomes provider of UID/GID for
     this process.

 (*) add-key [--session <name>] <data>

     Add a key to the primary or named session.

David