[cap-talk] Ambient authority in DVH

Charles Landau clandau at macslab.com
Tue Aug 1 17:48:17 EDT 2006


At 4:59 PM -0700 7/31/06, Jed at Webstart wrote:
>At 03:33 PM 7/30/2006, Charles Landau wrote:
>  >It may not be widely known that the Dennis and Van Horn paper,
>>despite its brilliant formulation of capabilities, also made use of
>>ambient authority. (In fact I didn't know it until just now, as I
>>re-read the paper.)
>>
>>"The meta-instruction
>>i := link <principal name>;
>>inserts into the C-list at index i a nonowned directory capability
>>pointing to the root directory named <principal name>. Using the
>>acquire meta-instruction, a computation can thus gain access to any
>>object in the directory structure of any principal, provided that the
>>directory items leading from the principal directory to the object
>>all contain F [free] indicators."
>>
>>Thus confinement is not possible in the system they describe.
>
>Hmmm.  I take your point.  It still seems to me still possible in DVH to do
>confinement more along the lines of the way Polaris does it by having
>a "principal" with few or now capabilities.  I guess there wasn't any
>notion of network access as there is today, so I think the notion
>of confinement might be considered in a somewhat different light.
>
>Still, what you say about "ambient authority" in the DVH paper,
>namely processes automatically and unavoidably getting all
>permissions of their principals, seems true.

At 12:10 PM -0700 8/1/06, Jed at Webstart wrote:
>At 03:33 PM 7/30/2006, Charles Landau wrote:
>>...
>>
>>It may not be widely known that the Dennis and Van Horn paper,
>>despite its brilliant formulation of capabilities, also made use of
>>ambient authority.
>
><namely, every process can access the permissions of its human
>initiator, it's "principal", thereby making it impossible to limit access
>by the Principle Of Least Authority>

No, it's worse than that. Processes can unavoidably get all the Free 
capabilities of *any* principal, just by specifying the principal's 
name.

>"When the supervisor creates a computation on behalf of
>a principal, it always places in the C-list of such a computation
>a directory capability with an O indicator that
>points to the principal's root directory. The principal is
>then said to own this computation and each of its processes.
>These processes are then permitted to exercise powers of
>ownership with respect to objects owned by the principal."

That would also be ambient authority, except that you may remove 
(ungrant) the directory capability before you start any processes in 
the new computation.

>Was the notion of permissions for users/Principals distinct from those
>for processes in the PDP-1 supervisor as implemented (as distinct
>from as described in DVH)?  Do you know Charlie, Bill?

IIRC, there was no concept of users or principals in the PDP-1. 
Certainly there was no "link" meta-instruction. The system was too 
small to retain objects from one user session to another. (It had a 
total of 198K bytes of persistent storage.)

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.

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.

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


More information about the cap-talk mailing list