[cap-talk] Ambient authority in DVH

[Fred Spiessens]

Sorry, there is a flaw in my reasoning ...

On 1 Aug 2006, at 10:05, Fred Spiessens wrote:

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

Of course, that is what Charles said already, sorry about that. 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.

However, in that case, the supervisor can still choose to refrain  
from marking any capabilities as "owned". Then, there is no ambient  
authority.

> 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
>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk

-------
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/eb162c8d/attachment.html