[cap-talk] Reducing the authority of a file browser in a capability OS.

[David-Sarah Hopwood]

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 ? [...]
>>>>
>>>> [...] 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?
> 
> Say a word processor being called by clicking at a document in the GUI
> lets ignore associations for the moment.  Note I distinguish a file
> explorer/ browser window here as a folder with files on the desktop and
> not a file/open dialog.  If you click on a doc file with the browser ,

[I.e. indicate to open the file for editing, which should probably not be
a single-click.]

> the file explorer browser
> will invoke via a file association the word processor it will then pass
> in its own browse capability to the file to indicate the file ( this
> being more secure than passing in the file name) . The word processor
> itself will check if it has a higher level capability for the file.

Why would the wordprocessor already have a more powerful capability?

First, you don't appear to be distinguishing between applications and
application instances. This is a common mistake that almost inevitably
leads to systems that require excess authority.

The user has only just indicated that they want *a new instance* of the
wordprocessor to be able to edit the file. For either the instance or
the application to *already* have a capability to do that is not needed,
and would defeat the advantage of the powerbox pattern in maintaining POLA.

> I suppose an alternative would be for the association to be a capability
> which contains both the R/W rights and the invocation of the word processor.

The aim is to minimize the amount of code that we have to review in order
to ensure that a given file only gets edited by a new instance of the
intended application, and only when the user has indicated that it should
be edited.

Here's one way of achieving that. Assume that files are associated with
their types. Suppose we have a relied-on confined BrowsingManager component
with the following facets:

  makeBrowsingFileSystem(baseFileSystem) :FileSystem
    return a view on baseFileSystem in which each file capability is
    wrapped to give a browse capability.

  putAssociation(fileType, appFactory) :void
    set the application factory for a given file type.

  getAssociation(fileType) :any
    return the application factory for a given file type.

  open(browseFile) :void
    if browseFile is one of my browse capabilities, unwrap it, look up
    the associated application factory, create a new instance of the
    application, and pass the unwrapped capability to that instance.

Now we [*] create an instance of a BrowserManager, initialize its file
associations, use it to create a BrowsingFilesystem, and pass the
BrowsingFilesystem and a capability for the BrowserManager's 'open' facet
to the browser factory. The browser implementation, which should also be
written in a capability-secure language since it's a critical component,
can limit access to the 'open' capability to a small part of its own code.
Even if it doesn't, we know that use of the 'open' facet can only cause
files to be opened with their currently associated applications.

[*] That is, code that enforces the policy we want -- for example the
    code that creates the initial browser for a user account, or that is
    creating an attenuated browser.

Code that has the 'putAssociation' facet can dynamically change the
associations, so the user can be allowed to do that via a relied-on UI,
which can be reviewed separately to the browser. (An alternative design
would have the creator of BrowserManager pass in the association table,
but that's just a detail.)

Let's extend this in order to associate previewers with particular
types. A previewer is a resource-limited pure function that takes as
input the contents of a file (as a lazy input stream), its type, and
the dimensions of the desired preview, and returns the data of a preview
image. This would add the following facets to a BrowserManager:

  putPreviewer(fileType, previewer) :void
  getPreviewer(fileType) :Previewer
  preview(browseFile, dimensions) :ImageData

Suppose now that we want the browser to be able to display the preview
but not read its image data (so that it obtains no information about the
file contents via the preview). Instead of giving the browser the 'preview'
facet, we can give it an attenuated version that calls a

  makeDisplayOnlyImage(imageData, dimensions) :DisplayOnlyImage

facet of the window system on the result of 'preview' before passing
it to the browser. This would validate the image data and return a sealed
DisplayOnlyImage that can only be unsealed and displayed by that window
system instance, in a window that does not allow pixel data readback.

It may be that files don't always have known types. In that case we can
add a resource-limited pure fileTypeGuesser function, that takes the
contents and extension of a file and returns its guessed type.

Notice that:
 - We can attenuate any of the facets in order to enforce additional
   security policy. For example, if we want to enforce that the
   applications associated with particular types are confined, we
   can do that by applying an auditor to their application factories.
   Or, we can attenuate 'putAssociation' so that it enforces such a
   restriction for all new associations. This depends critically on
   all authorities being represented by capabilities.

 - No additional mechanisms were needed besides object encapsulation
   and rights amplification (identifying and unwrapping browse
   capabilities requires the latter). In particular there is no
   implicit amplification occurring on IPC.

 - The approach is quite "object-oriented", but with slight differences
   from the most obvious OO design. For instance, 'open' and 'preview'
   are facets of a BrowserManager rather than being methods of a wrapped
   file, so that we can restrict access to (and attenuate) those facets
   independently of the browse capabilities. In the example above we
   depended on that to enforce the display-only property of preview
   images, without changing the BrowserManager (which doesn't know about
   or have access to makeDisplayOnlyImage).

 - I estimage it should be possible to implement the BrowserManager in
   no more than 30 lines of E excluding comments. (Yes, that's a
   challenge :-) For extra credit, run the app factories and previewers
   in separate vats.)

-- 
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/20091222/0c2a6ce2/attachment.bin