[cap-talk] Re: "capabilities" as data vs. as descriptors - OS security discussion, restricted access processes, etc.

Jed Donnelley jed at nersc.gov
Tue May 4 00:23:39 EDT 2004


At 05:38 PM 5/3/2004, David Hopwood wrote:
>>...
>[...]
>>1. Definition of what you might call an Internet capability model. This
>>  could be something along the lines of:
>>http://www.webstart.com/jed/papers/Managing-Domains/#s13
>>though I think modern encryption technology would suggest a
>>  rework. The basic idea would be to define a protocol for sending
>>  blocks of bits that:
>>a. Can securely represent the right to do anything that a service
>>  (server) process might chose to make available.
>
>An essential property of capabilities is that the designation of a
>thing, and the authorization of access to that thing, are inseparable.
>Jed's definition doesn't capture this requirement -- a. does not clearly
>distinguish capabilities from entries in Lampson's access matrix, or
>ACL entries.

I'm not sure why you say the above.  Certainly in the definition I
was referring to a protocol that combines the naming or a resource
with the right to access the resource.  However, from my perspective
I was not limiting the implementation.  E.g. I consider all the mechanisms
in the Managing Domains paper as fair game whether they be an
ACL mechanism (encrypted address or not - e.g. as I noted the
essentially ACL mechanism used in the DCCS mechanism:
http://www.webstart.com/jed/papers/DCCS/
even though at the user level the model was pure descriptor
based capabilities) an encrypted address version of ACLs,
capabilities as passwords, or the public key mechanism
that is there.  From the perspective of the program using
the protocol the sharing is of a resource with the name and
the rights to access combined.

>>b. Can be communicated securely - hopefully without contacting
>>  the service process except of course when it is the source or
>>  destination of the rights communication directly.
>>c. Is safe from evesdropping. That is, the form that the capability takes
>>  when it's in, say, a processes memory space or in an email message,
>>  cannot be used by any entity other than the owner of the memory
>>  space (a process) or the email (presumably a person).
>
>Why should a process' memory space be considered vulnerable to eavesdropping?

Because when I take a dump to a consultant they can see what's there.
Also I can be looking at memory with a debugger and have somebody
look over my shoulder - e.g. just as with reading email.  Certainly I can
and should be careful with such leaks of information.  However, I feel that
data that grants access rights for an extended period of time fall into
a category of information that is more sensitive - just as one shouldn't
send passwords through email or leave them in a processes memory
during debugging.

>It isn't realistic for a system to provide any meaningful security properties
>if process memory spaces are readable by adversaries (either directly or in
>the form in which they are swapped to secondary storage). E-mails and other
>unsecured transport protocols are a different matter, of course.

I agree subject to the above caveat.

>In any case, this criterion is too vague about which parties should be
>considered to be "eavesdropping", as opposed to having legitimate access.
>At <http://www.waterken.com/dev/YURL/Definition/>, there is a more precise
>attempt at defining a criterion that covers both b. and c. as they apply
>to messages.
>
># The y-property
>#
># Briefly stated, the y-property is: "The introducer determines the message
># target."
>#
># The y-property means that only the introducer has the privilege of
># determining the recipient of a message sent to the introduced site and
># the processor of the sent message. The introducer is the site authorized
># to write to a communication channel read by a client site. The introducer
># uses the communication channel to provide a URL to the client site. The
># URL identifies the introduced site. The introduced site is a site selected
># by the introducer. The client site is the site that receives the URL and
># uses it to send a message to the introduced site. Receiving a message means
># having access to the plaintext of the message. Processing a message means
># producing a response message which the client site will accept as an
># authentic response to the sent message.
>#
># The y-property is the result of applying the principle of least privilege
># to the fact that the introducer decides which site to introduce.'

The above to me seems fine.  To me it looks a lot like:

http://www.webstart.com/jed/papers/Managing-Domains/#s5

Perhaps any differences are a matter of emphasis?  Still, I think
that model is fine.

>[In the Web calculus, URLs are used as representations of distributed
>capabilities, but if that assumption is removed, the y-property applies
>to messages in any capability system. "Response messages" can either by
>supported directly by the system, or in terms of one-way messages by using
>continuation capabilities.]
>
>>d. Extra points for including a rights reduction mechanism that doesn't
>>  require permission from the server.
>
>This follows from the ability to program services that act as facets on
>other services, and so it doesn't need to be part of a definition of
>capabilities.

Implicit in what I was referring to above (goodness, I hope that simple
email doesn't get blown up out of proportion) was the assumption
that proxying wasn't required to as I assume you mean when you
say "act as facets".  The idea of the network capability is that a right
can be communicated in a message and the sender can get out of
the way.  I was hoping for a mechanism whereby, using the terminology
in the YURL document (to the best of my understanding):

Alice has a YURL for a resource, let's say serviced by Carol.  Alice
wants to pass the right and name (the capability) to that resource
to Bob, but with reduced access.  E.g. if Alice had a RW file capability,
she wants to pass a RO file capability to Bob in such a way that:

1.  Alice doesn't have to get involved in the requests from Bob to Carol, and

2.  Carol can correctly restrict the rights to the resource - in this case 
to RO.

>I have to ask: why is another definition of capabilities needed?
>Aren't the definitions in
>  - Paradigm Regained <http://www.erights.org/talks/asian03/index.html>,

Seems to refer to the Dennis and Van Horn capability model

>  - the "Ode" <http://www.erights.org/elib/capability/ode/index.html>,
>  - or on the C2 wiki <http://c2.com/cgi/wiki?CapabilitySecurityModel>,
>sufficient

I'm sorry if you felt I was in some way trying to redefine the notion
of capability.  What I had hoped to do was suggest some properties
of value in a protocol for communicating capabilities on a network.

As you note in:

http://c2.com/cgi/wiki?CapabilitySecurityModel

that you refer to above, there are many nuances on the capability
notion.  They all do seem to integrate the identity and the rights
to a resource, but they are implemented in a variety of ways in
a variety of situations with many consequences for their use.

My interest is in ways that work in a network protocol.  Call it
a YURL if you like.  Regardless, I would still like to be able to
"paste" (might require a transformation that I can do locally with
my private key and the public key of the recipient) one into an
email and not have somebody looking over my shoulder
at my email or at a printout of same get the right to the resource.

>This is not meant as a criticism: it would be really useful to know why
>"the capabilities people (them) and the nym people (us) haven't really
>seen eye to eye on the lucidity of each other's documentation."

Can you help me to understand who the "nym" people are?


--Jed http://www.nersc.gov/~jed/ 



More information about the cap-talk mailing list