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

[Matej Kosik]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rob Meijer wrote:
> On Thu, September 4, 2008 10:30, Matej Kosik wrote:
> 
>>> I think running plugins with least authority at this stage should be
>>> mostly about sandboxing and IPC techniques in order to confine the
>>> plugin
>>> process to least authority, and much less about using fine grained ocap
>>> enviroments to confine each object within the plugin to least authority.
>>>
>>> In Linux you could use AppArmor to confine access to the filesystem to a
>>> minimum, uid based rules in iptables to deny all initiation of
>>> networking,
>>> and unix domain sockets for communication of filesystem and networking
>>> handles. Running the plugin under a uid that is denied networking
>>> initiation with a restrictive AppArmor profile and communication to the
>>> browser using one or more unix domain sockets as IPC channel would get
>>> you
>>> prety close to least authority.
>> You cannot decide the security policy for an application if you do not
>> know what authority it requires.
> 
> Agreed, but the issue is plugins not applications in general, and it would
> seem that the most appropriate way for a plugin to receive its authority
> is by the intermediation of the main program, not by independant access to
> resources the OS offers.
> 
>> For example, if you banned by default all network access to all Flash
>> applications, some useful Flash applications would stop working because
>> they indeed need to make TCP connection to a remote machine.
>>
>> Can you handle this situation with AppArmor/... ?
> 
> AppArmor only to limit access to the 'filesystem' to the bare minimum,
> iptables can be used in addition to deny all 'network' communication
> initiation by a specific uid. If the plugin process runs under such a uid,
> it can not 'connect', but it should be able to use connected sockets that
> it gets passed by the main application process, the same way it can read
> from or write to a file using a handle passed by the main application
> process.

Ok. This scheme (interactive powerboxes) could work. It may be a
reasonable policy by default.

For particular cases it might be very useful also to allow
non-interactive powerboxes that would be realized by splitting the whole
(e.g.) Flash application into two parts
- - untrusted (with by default minimal authority)
- - trusted (with ambient authority)
The purpose of the trusted part would be to enforce the security policy
(by giving the untrusted part only those capabilities it needs).

It might perhaps be weird to regard mobile code as trusted but
- - if it is developed in-house
- - if it is audited by trusted auditor
- - if the user can check the code itself
then the user (or sysadmin) might gain confidence to mark a given piece
of code as trusted.

Trusted part should be (and I firmly believe that could be) tiny. This
can make auditing practical.

If the user had to drag-and-drop those capabilities again and again,
running certain Flash applications that need considerable authority,
such as opening several sockets; opening and closing sockets again and
again, it would be too annoying to rely on the "interactive powerboxes".

Additionally, via "noninteractive powerboxes" we can enforce more
ambitius security policies conveniently (easily at the programming side
and conveniently at the user side).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjBGN0ACgkQL+CaXfJI/hh5WwCfbDxC0DlCwXBM+C4qrdIeZmJJ
Cy0An3dr1VcJLMX81PQfUXkVjRxEHtsw
=sBdK
-----END PGP SIGNATURE-----