Google isn’t the only company toying with the idea of a secure operating system based around a web browser. Back in February, researches at Microsoft revealed details about Gazelle. Gazelle claims to be “a multi-principal OS construction of a secure web browser. Gazelle’s Browser Kernel exclusively provides cross-principal protection and fair sharing of all system resources.”
Like Chrome OS, which is built on top of Linux, Gazelle isn’t really a new operating system. Rather it is a layer that extends the browser’s security model down into the operating system level. Key to system is the idea of a “principal”, which in this case is the triple of protocol, domain-name, and port. Each combination is isolated from any other combination at the process level.
To protect from issues like cross-site scripting attacks, pages can only directly render content from one principal. Content from other principals is off-loaded into a another process specifically created for that principal. Communication between principals is done via the “Browser Kernel”. The Browser Kernel is a restricted OS process written in C# that facilitates inter-process communication. XML-based messages are sent between the Browser Kernel and the various processes using named pipes. As each process completes its rendering, the results are composed into a final image for the browser by the Browser Kernel.
Gazelle has numerous features targeting specific browser vulnerabilities such as plugins, mixed HTTP/HTTPS, and the “recursive mashup attack”.
Plugins. Gazelle enforces the same-origin policy on plugin content. That is, plugin content runs as the principal of its origin (and not as the principal of its host page). Since plugins are a source of rampant vulnerability growth, enforcing policy on plugins in Browser Kernel is critical for containing the damage caused by an exploit. Existing plugin software must be adapted (ported or binary-rewritten) to use Browser Kernel system calls to accomplish its tasks. There are 34 out of top 100 Alexa sites that use Flash plugins and no other kinds of plugins are used. This indicates that by porting or adapting Flash alone can address a significant portion of the plugin compatibility issue.
HTTPS inclusion of HTTP scripts and CSS. In Gazelle an HTTPS principal cannot include an HTTP script or CSS content. Other types of content, such as images and plugins, will be run in the process belonging to the hosting principal. This policy could be easily changed in Gazelle; however, by preventing HTTPS content from including HTTP provided scripts and CSS, Gazelle enforces stronger security against a network attacker. Since the top 100 Alexa sites don’t use SSL, we identified a few different sites that provide SSL sessions for parts of their web application: amazon.com, mail.google.com, mail. microsoft.com, blogger.com, and a few popular banking sites that are outside of the top 100. These sites don’t violate our policy.
Strict child-only navigation. A landlord frame can only cause navigation in tenants and has no control over frames belonging to the tenants or other principals. Sites that attempt to navigate descendants other than direct children will be unable to do so in Gazelle. By limiting the scope of navigation, Gazelle is able to prevent malicious web pages from navigating frames in benign web applications. This type of attack was previously analyzed by Barth et al. and presented as the “recursive mashup attack”. We were unable to automatically test sites for violations of this policy with our compatibility testing framework.
This level protection isn’t cheap. It can double rendering time on complex pages such as the nytime.com when cross-origin frames are involved. However much of this can be minimized with more work on the image composition portion of the Browser Kernel.
You can read the entire research paper and see a comparison to existing browsers such as Google’s Chrome on the Microsoft Research website.