A Microsoft Research team led by Helen J. Wang has created Gazelle (PDF), a browser-based OS, with the declared intent to tighten security when going online.
Gazelle is not a new operating system like Windows but a new type of browser that has a kernel acting as a multi-principal operating system responsible for managing resource protection and sharing resources between various web site principals. A security principal is “an entity that can be authenticated by a computer system or network. Authentication is the process of validating and confirming the identity of such an entity.” Janie Chang, a Microsoft Research team member, defines what a browser principal is and explains why adequate security matters:
In browser parlance, a principal generally equates to a Web site. Given that there is usually just one user at a time on a PC, the sharing of resources is actually across applications from different origins; in the case of Web pages, each page could consist of content from different principals, each staking out a share of computing resources. The browser is therefore the natural choice of application platform for managing principals and resource requests.
A Web page might offer content such as ads or newsfeeds from other Web-site principals. Yet to the browser, all these principals coexist in the same process or protection domain. An ad containing malicious or poorly written code could hog the network connection, degrade performance, freeze the entire page, or crash the browser. In a browser operating system, a “bad” principal would not be allowed to affect other principals, the browser, or the host machine.
Wang et al. define a principal as a web site “defined in the same-origin policy (SOP), which is labeled by a web site’s origin, the triple of (protocol, domain name, port).” To enforce principal protection, a browser kernel is introduced between the principals and the operating system as shown in Figure 1:
The browser kernel runs in a separate protection domain and interposes between browser principals and the traditional OS. The browser kernel mediates the principals’ access to system resources and enforces security policies of the browser. Essentially, the browser kernel functions as an operating system to browser principals and manages the protection and sharing of system resources for them. The browser kernel also manages the browser chrome, such as the address bar and menus. The browser kernel receives all events generated by the underlying operating system including user events like mouse clicks or keyboard entries; these events are then dispatched to the appropriate principal instance. When the user navigates a window by clicking on a hyperlink that points to an URL at a different origin, the browser kernel creates the protection domain for the URL’s principal instance (if one doesn’t exist already) to render the target page, destroys the protection domain of the hyperlink’s host page, and re-allocates and re-initializes the window to the URL’s principal instance.
Wang et al. compare current security measures existing in Google Chrome with those implemented in Gazelle. Google Chrome has the following process models: monolithic process, process-per-browsing-instance, process-per-site-instance, and process-per-site. A browsing instance is made up of all interconnected windows, frames and sub-frames, while a site instance is a collection of pages coming from the same site and existing within a browsing instance. Finally, a site is defined as “set of SOP origins that share a registry-controlled domain name: for example, attackerAd.socialnet.com, alice.profiles.socialnet.com, and socialnet.com share the same registry-controlled domain name socialnet.com, and are considered to be the same site or principal by Chrome.” According to Wang et al.,
Chrome uses the process-per-site-instance model by default. Furthermore, … Chrome’s current implementation does not support strict site isolation in the process-per-site instance and process-per-site models: embedded principals, such as a nested iframe sourced at a different origin from the parent page, are placed in the same process as the parent page. The monolithic and process-per-browsing-instance models in Chrome do not provide memory or other resource protection across multiple principals in a monolithic process or browser instance. The process-per site model does not provide failure containment across site instances. Chrome’s process-per-site-instance model is the closest to Gazelle’s two processes-per principal- instance model, but with several crucial differences: (1) Chrome’s principal is site (see above) while Gazelle’s principal is the same as the SOP principal. (2) A web site principal and its embedded principals co-exist in the same process in Chrome, whereas Gazelle places them into separate protection domains. Pursuing this design led us to new research challenges including cross-principal display protection. (3) Plugin content from different principals or sites share a plugin process in Chrome, but are placed into separate protection domains in Gazelle. (4) Chrome relies on its rendering processes to enforce the same-origin policy among the principals that co-exist in the same process. These differences indicate that in Chrome, cross-principal (or - site) protection takes place in its rendering processes and its plugin process, in addition to its browser kernel. In contrast, Gazelle’s browser kernel functions as an OS, managing cross-principal protection on all resources, including display.
Comparing Gazelle with IE8, Wang et al. notice that
IE 8 uses OS processes to isolate tabs from one another. This granularity is insufficient since a user may browse multiple mutually distrusting sites in a single tab, and a web page may contain an iframe with content from an untrusted site (e.g., ads).
The overall conclusion of the research team is:
Fundamentally, Chrome and IE 8 have different goals from that of Gazelle. Their use of multiple processes is for failure containment across the user’s browsing sessions rather than for security. Their security goal is to protect the host machine from the browser and the web; this is achieved by process sandboxing. Chrome and IE 8 achieved a good milestone in the evolution of the browser architecture design. Looking forward, as the world creates and migrates more data and functionality into the web and establishes the browser as a dominant application platform, it is critical for browser designers to think of browsers as operating systems and protect web site principals from one another in addition to the host machine. This is Gazelle’s goal.
A Gazelle prototype has been built on IE7 using its backward compatibility parsing, DOM management and JavaScript engine. The performance of the browser is reported as comparable with that of IE8 and Google Chrome. Cross-origin script source protection is addressed by using the architecture shown in Figure 2. The idea is to sandbox the plug-in code in order to isolate any malicious activities and also let the browser run in case the plug-in fails.
This research project raises many eyebrows of those fearing Microsoft has not ceased their plan to fully incorporate a browser in the operating system. Such a move would certainly be a major blow to many companies because the browser tends to be the dominant application on the desktop. Microsoft assures us that this is not their intent but rather to increase browsing security. Currently, Gazelle is just a research project and only time will show if it will become a product or at least if it will be incorporated in IE and what room is left for other browsers and online applications running on Windows.