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

[David-Sarah Hopwood]

Ben Kloosterman wrote:
>  >> >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 .  Your only open to
>  >> confused deputies if you extend that R/W to look in the users and user
>  >> groups capabilities instead of the application.
>  >>
>  >You can get a confused deputy any time there is an increase in
>  >permission on a delegation.  Consider Norm Hardy's compiler example.
>  >Say that I have a capability that lets me read the log file.  If I
>  >delegate it to the compiler, and the compiler receives it as a R/W
>  >capability, I could induce the compiler to use that capability to
>  >clobber the log file.
> 
> 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)?

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