[cap-talk] Ambient authority in DVH

[Fred Spiessens]

On 1 Aug 2006, at 22:48, Charles Landau wrote:

>
> At 10:29 AM +0100 8/1/06, Fred Spiessens wrote:
>> I think it makes sense for a system to allow its human Principals to
>> freely distribute their "owned" capabilities. That kind of "ambient
>> authority" is perfectly all right
>
> The "link" meta-instruction allows you to obtain any "free"
> capability of any principal. This is *not* OK because it prevents
> confinement.

Charles, I agree that "place", followed by "link" and "acquire" can  
provide ambient authority, and that is *not* OK.
I think it would be OK though, if  "acquire" was not possible in  
"Inferior Spheres of Protection".

>
> The paper does say (p.145):
>
> "Computations have broad powers with respect to owned computing
> objects, through mechanisms to be described. In the case of an owned
> segment, for example, a computation may delete the segment, and grant
> or deny other computations access to the segment."
>
> Such mechanisms are not described in the paper (that I could find).
> In the case of granting or denying, we may give DVH the benefit of
> the doubt and assume the grantor must have a capability to the other
> computation.
>
>> I thought the "Inferior Spheres of Protection" provided a way to
>> prevent subprocess from acquiring any new capabilities that where
>> made available by other Principals, but this may not be so.
>
> Not so. The "link" meta-instruction is available to any computation.

I agree.
( I said "I thought .. " to indicate what I thought before I realized  
my mistake.)

>
>> However, in that case, the supervisor can still choose to refrain
>> from marking any capabilities as "owned". Then, there is no ambient
>> authority.
>
> A capability marked "free" can be taken by any computation. It is the
> user, not the supervisor, that chooses whether to mark a capability
> as free.

That is true. But my conjecture stems from the assumption: you need  
to own a capability before you can "place" it into a directory.

The paragraph were the "place" meta-instruction is defined starts  
with: "Ownership of an object implies the ability to modify it,  
delete it, and grant access to the object by other principals."

The meta instruction
  "place {P,F} i, <name component>, j"
  is then clarified:
  "Here i must be the index number of an owned directory capability.  
An item is inserted in directory i associating the capability having  
index number j with <name component>".

In that clarification DVH don't explicitly say (repeat) that j has to  
be owned too, but I think we must infer that anyway, from the first  
sentence in that paragraph.

I admit it is not completely unambiguous, but I think we are supposed  
to interpret the first sentence as: you must have ownership to a  
capability to be able to grant access to that capability by other  
principals (via the "place" instruction). I don't think there is much  
use for the  "ownership" concept, if not for this purpose.

In addition to refraining from marking capabilities as "owned", the  
supervisor should indeed also refrain from marking the entries in the  
principal's root directory as "F" (free).

Fred.

PS. I think this is a very useful discussion. Thanks for starting it.


-------
Fred Spiessens
Research Scientist Secure Software at
Cork Constraint Computation Centre
http://4c.ucc.ie/~fsp


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20060802/1483620a/attachment-0001.html