[cap-talk] Google Chrome - web browser with sandboxed rendering
david.hopwood at industrial-designers.co.uk
Sat Sep 6 16:47:51 CDT 2008
Ben Laurie wrote:
> On Fri, Sep 5, 2008 at 10:12 PM, David-Sarah Hopwood
> <david.hopwood at industrial-designers.co.uk> wrote:
>> 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: [...]
> This is effectively what factotum in plan-9 does.
> The problem with this design, though, is that it relies on the user to
> know that "aha, if an app wants to use the POP3 protocol, then I
> should insist that it uses the trusted POP3 component". Tying this to
> port 110 is obviously not a great idea, so we're back to UI that is
> going to confound most users, surely?
No. It doesn't have to be the end-user that configures the installation
endowment. The application would be provided together with a description
of the authorities it is to be endowed with. This description might be
written or reviewed by an OS distribution, or an organisation's IT
department, or some tech-savvy relative who set up your computer for you.
We are only relying on this description to have been reviewed by someone
who knows that a mail user agent should not have arbitrary socket access.
The end-user doesn't edit this description (they can, but the "most users"
you are referring to will not).
It might also be technically possible for socket access to be granted
dynamically, but that is a rare enough requirement that the associated
user interface can be suitably scary, and can explicitly say that socket
access is needed only in exceptional cases, when no trusted proxy is
In any case, the mail user agent programmer has an incentive to use the
trusted POP3 component in preference to direct socket access:
- it saves them effort, because they don't have to reimplement
POP3-over-TLS or APOP authentication;
- it limits the damage that can be done if the MUA is subverted
(much more can be done if the MUA is written in an object-capability
language, but this much is a start).
The aim of this design is not *primarily* to protect against a hostile
mail user agent (although it does so as a side effect provided that the
installation endowment has been properly reviewed). It is to protect
against a mail user agent that may be subvertable by mail content that
it tries to process. That is by far the more important problem, as
demonstrated by the prevalence of attacks on MUAs that have not been
written to be hostile.
More information about the cap-talk