# Genode Web-Browser Demo (2/4)

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:

The plugin above consists of multiple processes and uses the same binaries as the Genode system you are running. The most significant advantage of this technique, however, is the degree of isolation between browser and plugin. Even though both are integrated into one GUI, they are executed isolated from each other. Just press the X-Ray key (usually this is `ScrLock`) to reveal their respective identities. The browser window is labeled as "menu -> browser -> arora", which means that "arora" is a child process created as part of the "browser" subsystem, which, in turn, was created by the "menu". In contrast, the plugin is labeled as "loader -> init -> framebuffer". It is a subsystem spawned by a "loader" service running independently from the menu. The following diagram depicts the scenario:

The solid lines are parent-child relationships, the dotted lines are client-server relationships as routed through the process hierarchy.

The browser downloads the plugin and hands it over to the loader service, accompanied with the (memory) resources the loader needs to execute the new plugin subsystem. Because the plugin is executed by the loader, not by the browser directly, the browser has no direct power over the plugin. It can tell the loader about the position on screen, where the plugin should be presented, but it can neither interfere with the execution and data of the plugin, nor observe user input referring to the plugin. The plugin, in turn, does not even know about the existence of the browser. In the extreme case, if either of the two crashes, the other remains unaffected.

For a test demonstrating that both subsystems are really independent, you may lock out the browser from the GUI by force using the kill key (`Print`). Scroll up to make the plugin visible and hit the kill key. After the screen turns reddish, click onto the browser (outside the plugin). You will see that the plugin will remain intact. However, to proceed with the demo, you will need to stop and restart the browser demo from the main menu.

# Pretty geeky, but is it useful in practice?

Think of a trusted service provider such as a bank. When performing online banking via a normal web application, you type in your PIN and TAN numbers into the browser which relies on millions of lines of code - an enormous attack surface for malware such as trojan horses. In contrast, if the trusted service provider offered a Genode subsystem as plugin, most of this complexity including the whole browser would be removed from the critical path. A plugin started by Genode's loader relies on 35K lines of code only (the microkernel plus the Genode base system). By delivering the (trusted) client application each time the user visits the web site, the service provider can always deliver the latest version. The plugin can be a single program or a complete subsystem. It can even bring along its own TCP/IP stack connected to the network via Genode's low-level network bridge. This way, the plugin will actually use a distinct IP address as if it was executed on a separate machine.

Continue: Booting a Linux kernel in the browser