[cap-talk] Ambient authority in DVH

[Fred Spiessens]

On 30 Jul 2006, at 23:33, 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.
>
> They go on to illustrate how to do ad-hoc access control, based on a
> meta-instruction that gives the principal name of a caller.
>
> I believe the evils of ambient authority simply weren't known at that
> early date.

In defense of DVH, 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, just as it  
is OK for my shell process to inherit all my own capabilities, as  
long as it can spawn subprocesses with a precisely defined subset of  
all my capabilities. DVH allows this via the meta-instructions  
"create sphere", "grant", "start", and a set of error handling meta- 
instructions. I therefore think we should not refer to this as  
ambient authority, but as capabilities acquired by initial conditions.

Human communication and "proxying" (I do things on the computer for  
you, using my password) cannot be prevented anyway. All the system  
must prevent is:
1) that Principals are being "forced" to share their capabilities.
2) that Principals are using capabilities they were not aware they had.

If my interpretation of DVH is correct (it may very well NOT be,  
because it is a very rich paper), both requirements are OK in DVH.  
For 2): I think you have to explicitly "acquire" capabilities that  
were made available to you by other Principals.

Therefore, in a correctly implemented DVH system, there is also no  
need to use the Polaris (HP) trick.

The fact that the capabilities must be "owned" to allow a Principal  
to distribute them, only gives the supervisor an extra possibility to  
restrict the maximally possible set of initial capabilities any  
process can have.

Fred.

-------
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/20060801/b0ebed35/attachment-0001.html