Current-generation web browsers execute browser plugins either as part of the
web browser or within a specially tailored execution environment running
more-or-less independently from the web browser. Plugins executed in the same
process as the browser itself are a stability and security risk, in particular
if the plugin code is highly complex third-party binary-only software. So
putting this code in a sandbox sounds like a good idea. But it raises a number
of questions: Which functionality should the sandboxing mechanism provide? How
does the security policy of the sandbox look like? How is it enforced? Who is
in charge of configuring this policy? How does the browser interact with the
sandboxed plugin in order to realize the visual integration into the website? Where
do the resources needed for constructing the sandbox come from?
Indeed, many hard questions.
On Genode, each process lives in a Sandbox
In the domain of web browsers, these questions pop up right now and seek for a
solution. However, when replacing "sandbox" by "execution environment" and
"plugin" by "program", it becomes apparent that these questions are classical
operating-system issues.
The Genode architecture solves these issues by design at the OS level.
Each process lives in a sandbox, created, paid-for, and controlled by its parent.
Access control is denied by default and must be granted explicitly by passing
capabilities between processes. Since each process runs in a sandbox anyway,
there is no need for a browser-specific solution. We can just run an arbitrary
fully-featured Genode subsystem as browser plugin: