Re: MEMORY credential cache interop between Heimdal and MIT?

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

On Aug 29, 2007, at 9:46 AM, Howard Chu wrote:

>> And with it it has the same ownership issue as a regular ccache  
>> file. Also, access control is limited to what inheritance provides.
>
> Could you summarize these ownership concerns again, or point me at  
> an archived posting that enumerates these issues? I've missed some  
> context somewhere.

The context is that some of us would like to solve the AFS PAG  
(Process Authentication Group) problem the same way we solve the  
secure credential cache problem.  PAGs have better semantics than any  
extant Kerberos ccache implementation.

As such the historical contextual reference would be some old CMU  
paper that I won't take the time to find (right now anyway).  The  
paper IMO spends too much time on the "funny group number"  
implementation of PAGs, and not enough on the user-level semantics.   
(As Russ said, the "funny group number" implementation worked  
surprisingly well until about 5-10 years ago when Linus Torvalds and  
Apple, Inc., and maybe other people decided that the kernel  
modifications needed to muck around with group numbers were bad.)   
This has led to some unfortunate erosion in people's expectations  
from AFS capabilities.

 From an implementation standpoint, PAGs are efficiently searchable  
by a kernel filesystem module in order to match credentials to  
callers.  Since they're stored in the kernel there are syscalls to  
get/set/erase entries from user space.  The kernel module gets to  
implement the semantics that seem best, and I think the semantics  
they defined are pretty good.  Kerberos doesn't implement any kernel  
modules, and therefore has compromised their ccache scoping semantics  
(and associated security) to fit the available userland mechanisms.

The interesting thing about this thread, to me, is that we seem to  
have people interested in pushing the envelope, and using new  
userland capabilities to get better scoping semantics.

 From a user's perspective, a PAG is like a terminal login session  
with two exceptions.  First it's "secure";  you can't break into and  
access anything from another session (even with the same UID).   
Second, you can create new ones on the fly;  on AFS this is done by  
running "pagsh" and doing work under the new shell.

PAGs are inherited by sub-processes, including set-uid-root ones like  
lp (which is handy for printing files that live in AFS filespace).   
There is no set-pag-id capability.  Once you're in a PAG the only  
ways to get out are to create a new, empty PAG or to terminate the  
process (reverting to the parent's PAG as part of returning control  
to the parent).

A new PAG has no credentials.  You can test a program inside a new  
PAG without worrying that it might modify your files.

Credentials added to a new PAG do not "leak" to other processes on  
the machine.  You can create a terminal window with administrative  
credentials in its new PAG without worrying that a process run  
elsewhere might acquire the ability to do more than you intended.

When we talk to OS people about PAGs we usually get hung up on the  
"secure storage" issues, and don't necessarily get the inheritance/ 
scoping problem solved.  The Linux keyring implementation had issues  
along those lines, but I think (hope) that the implementation at  
least allowed PAG semantics to be implemented, even if it provided a  
bunch of other unimportant options.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu