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

[David-Sarah Hopwood]

Ben Kloosterman wrote:
> David-Sarah Hopwood wrote:
>> Ben Kloosterman wrote:
>>> Alan Karp wrote:
>>>> Ben Kloosterman wrote:
>>>>> 1) However I still want to cover upgrading the capability from say
>>>>> browse to R/W when a browse capability is received via iPC.
>>>>
>>>> Then you are enabling confused deputy attacks.
>>>
>>> How so ? This is merely using the browse capability to indicate which
>>> file and then looking up a r/w capability within the application ( and
>>> hence upgrading to the higher level R/W)  , If an R/W capability was
>>> passed in there would be no need for a lookup .
>>
>> Alan is right; there's clearly a confused deputy vulnerability here.
>> If the browse cap gets amplified/escalated to a r/w capability just
>> because it is the browser that is sending it, then "being the browser"
>> is an ambient authority.
>>
>> Note that the approach I suggested in which the browse cap is a sealed
>> r/w cap doesn't have that problem, because the unsealer is not ambient.
> 
> No I'm not trusting the browser anyone can send a File Explorer/browser
> or R/W capability in this case ( obviously this would be a browse
> capability on the file not the whole dir) .

I don't understand what you're proposing at all, then. Under precisely
what conditions are you suggesting that a browse capability gets amplified
to a r/w capability? I.e. what mechanism controls when this happens?

-- 
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/20091219/d2b77254/attachment.bin