[OpenAFS] Kerberos 5 cache in /tmp

[John Rudd]

On Apr 7, 2004, at 3:58 PM, Rodney M Dyer wrote:

> At 06:26 PM 4/7/2004, you wrote:
>
>> Not that an in-memory credential cache would make any difference in  
>> this situation.
>> If you have root privs you can access it.  This is true on Windows as  
>> well.  If
>> you are SYSTEM you can do whatever you want.
>
> True.  But that problem only occurs because the kernel code allows all  
> memory to be read by "root".  It would be nice if all OS's has a  
> "protected store" memory area who's sections could only be mapped to  
> each authenticated user.  Don't ask me how...I just work here.
>

Capabilities solve that problem.  With a capability OS, all OS objects  
(processes, files, directories, device drivers, etc.) are distinct  
entities that have a unique identity and a unique set of  
"capabilities".  The capability is like an ACL, in that it specifies  
exactly what each other object is or isn't allowed to do to that  
object.  In a combination of OO and AFS thinking, think of it like  
every object has a token, and instead of an AFS-like defined set of ACL  
attributes, every method for that object ("read", "write", "open",  
"delete", "send", "encrypt", "decrypt", etc.) has a list of other  
objects that may or may not use that method.

But that's a sort of shallow summary from someone who hasn't really  
looked at capabilities in a few years.  Unix would require a lot of  
re-working to function with capabilities (for one, the unix style  
permission model is _gone_ in a capability OS).  I'm not sure how well  
mach would adapt to it ... and I'm not sure what it would look like to  
have a mach kernel with a capability middle-layer and then a unix layer  
on top of that (but, that has been my idea about how to bring  
capabilities to unix).  It may end up that your "unix" environment ends  
up being 1 capability object, or something ... which means you're not  
really using capabilities within unix.

AFS and Kerberos have a problem here in that everytime you spawn a  
process or create a file, you's have to create a new principle.  So,  
instead of using AFS/Kerberos as your identity model, you have to think  
of the kerberos ticket or AFS token as a specific object, and then the  
ticket/token object has ACLs for who and what may access it (and how  
they may access it).


Anyways, for more info about Capabilities (now that I've mentioned them  
twice in a short time), here's some links:

(google search that has some good results)

http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF 
-8&q=Capability+Based+Operating+Systems&btnG=Google+Search

The first 3 major results are "EROS", "J-Kernel" and "Cap-lore".  EROS  
is a capability oriented OS, which looks interesting (and their "about"  
pages do describe the basic concepts of capability systems).  Cap-lore  
is oriented around the theories in general.  I haven't seen nor used  
J-Kernel.

EROS' description of Capabilities can be found at:

http://www.eros-os.org/project/novelty.html#capabilities

(I've also had the plan-9 people tell me that they think of their file  
name space to effectively be a capability system, in that being able to  
name an object is the same as being able to use/access it, so if you  
don't want your inheritors to access you, you remove yourself from  
their name space ... but it's not a strict one, because they can  
essentially add you back without your being able to deny that)