[cap-talk] Re: "capabilities", reading about "split capabilit ies", review, KeyKOS?

[Karp, Alan]

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed Donnelley
> Sent: Friday, May 07, 2004 6:53 PM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Re: "capabilities", reading about 
> "split capabilities", review, KeyKOS?
> 
				(snip)
> 
> But for a. I hadn't seriously looked at "split capabilities" 
> before.  Again
> following my effort to reduce what I see as side threads, let me ask
> a few questions about split capabilities.  For example, from:
> 
> http://www.hpl.hp.com/techreports/2001/HPL-2001-164R1.pdf
> 
> when it says (pg. 3):
> ____________________________________________________________
> Traditional capabilities, such as those shown in Alice's 
> capability list 
> above, have two
> problems. It is hard to revoke a capability [1, page 149] because the 
> system has no
> control over the passing of capabilities from one user to 
> another. The 
> number of
> capabilities in a system is also a problem because a 
> capability is needed 
> for each
> separately controlled access right on each resource. This 
> means that each 
> time a user
> joins the system, many thousands of capabilities need to be 
> issued; each 
> time a user
> leaves, they must be revoked. Combined, these two problems present a 
> challenge for
> system designers.
> _______________________________________________________________
> 
> Of course I'm not sure just what is meant by "traditional 
> capabilities".  As we
> have seen there seems to be a fairly wide variety of opinion 
> on that.  However,
> I'll take the capability concept in as broad a view as 
> possible (a communicable
> token representing an access right supported by a service 
> process).  With
> that broad view I don't see either of the above as issues.  
> As I noted, 
> revocation
> can be handled easily with a small amount of book keeping in 
> the server
> ("fork").  While it is true that a capability is needed for 
> each separately 
> controlled
> access right on each resource, where is the problem with 
> that?  It isn't like
> we're going to run out of bits.  I'm afraid I don't 
> understand why it would be
> imagined that "This means that each time a user joins the system, many
> thousands of capabilities need to be issued; each time a user
> leaves, they must be revoked."  I am unaware of capability systems in
> which the above is true.

First a remark on what I didn't understand at the time I wrote that paper.  The "name" part of a split capability is just a capability.  It conveys the right to send a message to the resource.  In fact, our first prototype did have a separate capability for each individually controlled set of rights.  The problem was that we attached between 100 and 100K Bytes of metadata to each capability, and we worried about storing it all.  It's not so bad when you consider things like files with only a few methods, but we also wanted to provide services that might have hundreds of them.  Hence, we split the right into two parts, getting the request to the resource and the specific method being invoked.  The first part carried the bulk of the metadata; the second part had none or only a small amount.

The remark about revocation came from thinking about object capabilities.  At that time, I didn't understand the caretaker pattern.  Even if I had, such a forwarder would have been pretty heavyweight in our system.  Another reason was that we wanted to allow either a sysadmin to be able to revoke the capability without relying on the server, something no doubt influenced by our enterprise background.  Also, we wanted to reduce the burden on the server's programmers by limiting how much security code they needed to get right.  Dealing with revocation would be more difficult than just deciding whether or not to honor a request.  Since all messages were mediated by the TCB, we had a single place where we could enforce the revocation request.

The commet on "many thousands of capabilities" comes from a remark made by Jonathan.  He expressed exactly this concern in an email on this list some two years ago.  We were able to emulate some of the standard access models, such as Unix file permissions, compartments, and MLS, with only a few "split" capabilities.  Configuring the permissions this way gave the processes ambient authorities, and we couldn't properly enfoce POLA, but we considered trading off configuration complexity for restricting authority a question of risk management.

				(snip)

> 
> I couldn't agree more.  Sounds like another vote against 
> trying to enforce
> confinement - this time with rights communication.  It's best 
> of course
> mainly in the sense that by trying to do such enforcement you stand in
> the way of legitimate POLA access control.

Even so, we did proxying by default for the reasons I gave in my earlier note.  The proxy had to take explicit action to get out of the path.  There's also the question of rights amplification that I believe is important.

> 
> Maybe I better stop there.  If I don't understand the premise 
> of "split 
> capabilities"
> (one for the resource and one for the rights), perhaps it isn't worth 
> proceeding
> until I do.  Otherwise the splitting would only seem to complicate 
> something that
> is otherwise simple.

A good analogy is Unix files.  If I have a name for a file in my chrooted directory, I can try to open it.  Whether I can open it for writing or not depends on a second piece of information.  The parts of the split capability are the name part and the write permission part.

				(snip)
> 
> --Jed http://www.nersc.gov/~jed/ 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 

________________________
Alan Karp
Principal Scientist
Technical Computing Research Group
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alan H Karp.vcf
Type: application/octet-stream
Size: 774 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20040510/3d0ae14d/AlanHKarp.obj