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

[Ben Kloosterman]

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

Yes that’s nice though it's arguable whether people are willing to do that for an edit, most people work with docs there whole life. You could use a my last work folder which allows 1 click edit.

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

I do distinguish ( though it gets harder with persistence and non file configuration)  , it was more the desire to make fewer all powerful pieces of code .

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

Its interesting to make alls these apps have even less authority. Though what I propose is far better than existing systems.  Though the amount of code that has this access is building we have the file/open dialog , the file explorer windows , the install/configure dialog. 

How does this work with programs or macros eg a mail merge that merges 20K documents beginning with ba*.docx in a  directory tree ? 


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

Yes quite nice.
 >
 > - 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.)
 >

I'll get there in a year or 2. 

Regards, 

Ben