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

[Rob Meijer]

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.



Rob