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

[Ben Kloosterman]

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

No the elevation code would run from the word processor.
 
 > - how did it get this authority?

The RW ?  It can only elevate to a RW the word processor would have.  The word processor may have the authority because it has RW authority to all the users doc files  or it may have it because the document was created with the word processor.


 > - why should it have it? (it certainly seems like excess authority)

The ability to escalate an incoming request to your defined authority would mean you could reduce the level of authority the caller needed. 

 > - why is it not represented as a capability, and not delegatable?

The ability to escalate , it certainly could be , since you can only escalate incoming capabilities to your own authority for the same file/cap  it seems there is no risk ?  Practically it's probably part of the Keyring and since all processes have this there is no need to pass it around. 

 > - why is it exercised implicitly when the browser sends a message
   by IPC to any other process?

Let me explain normally when you open a word processor in say Windows the UI goes winword.exe fileToOpen.docx ( and it knows its winword because it is associated with that document or is manually selected with openwith) . We don’t have such a command line so  the browser though we could send the filename.  However rather than send the file name  to indicate what you are trying to open you can send you browse capability ( if you had R/W you could send that ) which tells the system what the file is since the Capability is a reference to an underlying FileObject. 

All im doing is replacing the  lookup of "fileToOpen.docX" string which would search the capabilities Winword has access too, with a strongly typed mechanism where I send the Browse Capability ( which references a file) and the store can doing an exact type safe lookup.

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

Im just a bit cautious here as I have seen so many holes with file association and sending the R/W  seems to me to create more risk. 

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

I would agree if it was done in transmission but it gets done within the receiving process. 

Regards, 

Ben Kloosterman