[cap-talk] Reducing Ambient user authority in a Type Safe/Memory Safe OS.

[David-Sarah Hopwood]

Ben Kloosterman wrote:
>>> Only with extremely bad code ..  This is a specific API specifying a
>>> file to open ( for RW we are a word document here) .
>>>
>>> I would imagine the code being very similar to
>>>
>>> ProcessRequest  ( FileCapability fileToEdit) {
>>> [...]
>>>     if ( fileToEdit.Rights != FileRights.RW)
>>>     {
>>>         var result = KeyStore.FindUpgradeCapability( fileToEdit)
>>>         // trusted code that ensures capability is the same type
>>>         // (FileCapability) and refers to same file/inode
>>
>> What process is this code in, and why does it have the authority to
>> amplify any FileCapability to r/w (i.e. where did it get KeyStore from)?
> 
> The code is in a trusted system library but it runs in the programs
> address space ( really object space) ,

The browser program, I assume?

So the browser has authority to amplify any browse capability to a r/w
capability. This raises several questions:

 - how did it get this authority?
 - why should it have it? (it certainly seems like excess authority)
 - why is it not represented as a capability, and not delegatable?
 - why is it exercised implicitly when the browser sends a message
   by IPC to any other process?

This all seems strictly worse from a security point of view than the design
I suggested where the browse capabilities are sealed r/w capabilities. In
particular, the implicit amplification on IPC would interfere with splitting
the browser into multiple processes, and makes it unnecessarily difficult
to see where the amplification authority is exercised in a security review
(since only a small proportion of the browser's uses of IPC actually need
this amplification).

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20091221/df58026e/attachment.bin