Re: MEMORY credential cache interop between Heimdal and MIT?

[Howard Chu <hyc@highlandsun.com>]

Henry B. Hotz wrote:
> 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.

Ugh. I was writing AFS and DCE/DFS servers back in the mid-90s, I remember the 
"funny group number" hacks. I painfully remember when DCE decided that its 
version of PAGs ought to be different from AFS. sheesh.

The "leak-proof" semantics are trivially defeated though, by any desktop 
sharing software. Or even running GNU screen in multi-user mode. (I co-authored 
screen, and I use the multi-user feature pretty often.)

> 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.

The kernel hacks in AFS/DFS were only necessary because their respective 
filesystem drivers wanted to use those credentials instead of the standard Unix 
credentials. The reason we can have a discussion about userland solutions for 
Kerberos in general is because there are no kernel/filesystem considerations to 
muddy the water, the information is only needed in userland. If you decide that 
you want a credential cache that will also work for AFS and OpenDCE then 
efficiency will dictate bringing us back to kernel mode.

> 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.

It sounds like you're happy with the inheritance model and don't need anything 
else. But again, your assertion that strict inheritance in the implementation 
guarantees secure usage is false.

Also, despite the lack of a set-pag-id call, it was quite simple (at least in 
earlier revisions) to simply call setgroups() with the funny group numbers to 
assign a process to any PAG desired, or switch back and forth among many sets 
of credentials.

So, I think it's important to recognize that nothing you devise will be 
foolproof. Anyone who wants to shoot themselves in the foot and give away their 
security tokens can always find a way to do so, and even people who don't want 
to can frequently be tricked into doing so anyway.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/