[cap-talk] Google Chrome - web browser with sandboxed rendering

[David-Sarah Hopwood]

Ben Laurie wrote:
> On Thu, Sep 4, 2008 at 10:39 PM, James A. Donald <jamesd at echeque.com> wrote:
>> Ben Laurie wrote:
>>> I agree that the problem of making the security decisions is
>>> considerably harder than that of enforcing them.
>> Hence the powerbox user interface model of piggybacking permission on
>> designation.
> 
> This particular assertion is beginning to really bug me. Designation
> works fine for files, maybe, and for drag'n'drop, even more maybe (are
> you granting read? write? a communications channel? is it permanent or
> temporary? etc). But I've yet to see any evidence that it makes any
> sense at all in the context of, for example, sockets.

You can use it for sockets, but the problem there is that permission to
access a socket is too low-level to be an understandable authority for
most users.

The powerbox UI pattern is more appropriate for permission to access an
account for a particular protocol.

For instance, an UI for configuring email account settings could easily
be a trusted dialog (the one below is based on Thunderbird's current UI):

   -------------------------------------------------------------------------
   | E-mail account settings
   |
   | 'CapMail' is asking to configure a server and user account from
   | which it will be able to read e-mail.
   |
   | Server Type: [ POP3                v ]   Port: [ 110 ] (default 110)
   | Server Name: [ _                     ]
   | User Name:   [ _                     ]
   | Password:    [ ********              ]
   |
   | Use secure connection:
   |   ( ) Never   ( ) TLS, if available   (o) TLS   ( ) SSL
   |
   | [ ] Use secure authentication
   |
   |                    [ Grant ]          [ Cancel ]
   |
   -------------------------------------------------------------------------

('CapMail' is the pet name for the application that opened the trusted
dialog.)

So instead of getting authority to open a socket, the mail user agent would
get authority to open a session, that allows it to read e-mail only for the
given server and username. It doesn't get access to the password (which the
user might have reused in several places), only the ability to use the
password on this account.

This would be implemented by having a library of proxies for common
protocols:

  - Parts of the library (probably only small and easily reviewable parts)
    have to be trusted with arbitrary socket access.

  - The proxy for a particular protocol only has to be trusted with access
    to the given domain and port (under the assumption that the UI to
    specify the domain and port is trusted), and with the login details.
    Proxy instances are otherwise confined and memoryless.

  - The user agent application only has to be trusted with (revocable) access
    to the account; not with the login details for the account.

The proxy for each protocol needs to have just enough knowledge of the
protocol to be able to log in, and to enforce that the session stays in
that account (for example in POP3, it might have to filter out USER, PASS,
and APOP commands, if the server violates the spec and allows these other
than in the AUTHENTICATION state).

Note that we are not doing any more work here than is already done by
personal firewalls and by system libraries on existing operating systems.
In fact we're probably doing less work: on existing OSes there are very
likely to be several duplicates of this functionality, all of which have
to be secure.

Also note that the library is not conceptually part of the OS. If an
application needs some completely oddball protocol, it can provide its
own proxy for it, and then only that proxy needs to be reviewed in the
same way that it would if it were installed centrally.

This approach does not work so well for things like web browsers that need
to access many different sites. However, I don't think there's any need
to use a single approach for everything.

-- 
David-Sarah Hopwood