# Summary: Trust and Protection in the Illinois Browser Operating System In 2009 Internet Explorer, Chrome, Safari, and Firefox had 349 new security vulnerabilities. Vulnerabilities in web apps are widespread and increasing. Attacks on web apps, browsers, and operating systems are less common than web app vulnerabilities. This paper describes **Illinois Browser Operating System (IBOS)**, an operating system and a browser co-designed to reduce the [trusted computing base (TCB)](https://en.wikipedia.org/wiki/Trusted_computing_base) for web browsers. The primary goals are to enforce today's browser security policies with a small TCB, without restricting functionality and without slowing down performance. ## 5 key design principles 1. Make security decisions at the lowest layer of software. 2. Use controlled sharing between web apps and traditional apps. 3. Maintain compatibility with current browser security policies. 4. Expose enough browser states and events to enable new browser security policies. 5. Avoid rule-based OS sandboxing for browser components. ## Overall architecture IBOS architecture uses a microkernel approach with a thin kernel for managing hardware and facilitating message passing between processes. Web apps use these abstractions directly to implement browser functionality. The IBOS UI manager plays the role of the window manager for the system. Basic browser UI widgets, called the browser chrome, are displayed at the top of the screen. If traditional apps wish to implement the window motif, they can do so within the tab. The primary security policy that all modern browsers implement is the [same-origin policy (SOP)](https://en.wikipedia.org/wiki/Same-origin_policy). It provides isolation for web pages and states that come from different origins. The primary goal is to enforce browser security policies from within the IBOS kernel. The IBOS kernel upholds its security policies even if one or more of the subsystems have been compromised. ![IBOS NIC message passing](https://i.imgur.com/QcCn9qK.png) The figure shows how the IBOS subsystems interact when a web page instance from uiuc.edu issues a network request to foo.com. Subsystems are shown in boxes and solid and dotted arrows represent IBOS messages for outgoing and incoming data respectively. To download the image: 1. the web page instance will make an HTTP request that the IBOS kernel forwards to an appropriate network process. The network process forms a HTTP request, which includes setting up HTTP headers, 2. fetching cookies from the storage subsystem, 3. requesting a free local TCP port to transform this request into TCP/IP packets and Ethernet frames, and 4. sending it to network manager. The network manager notifies the Ethernet driver which 5. programs the NIC to transmits the packet out to the network. When the NIC receives a reply for the request, 6. it notifies the Ethernet driver. The driver subsequently 7. notifies the network manager, which 8. forwards the packet to the appropriate network process. The network process then parses the data and 9. passes the resulting HTTP reply and data to the original web page instance. ## IBOS labels - **web page instance** has one label, which is the origin of the main HTML document. - **traditional process** is labeled as being from "localhost" when they are created - **network process** has an origin label for the network resources it handles For all subsystems, security invariants are used that are assertions on all interactions between subsystems that check basic security properties. 1. All components can only perform their designated functions. 2. Drivers cannot access DMA buffers directly. 3. Devices can only access validated DMA buffers. 4. All of the key-value pairs maintain confidentiality and integrity even if the storage stack itself becomes compromised. 5. The kernel must route network requests from web page instances to the proper network process. 6. The kernel must route Ethernet frames from the NIC to the proper network processes. 7. Ethernet frames from network processes to the NIC must have an IP address and TCP port that matches the origin of the network process. 8. HTTP data from network processes to web page instances must adhere to the SOP. 9. Network processes for different web page instances must remain isolated. 10. The browser chrome and web page content displays are isolated. 11. Only the current tab can access the screen, mouse, and keyboard. 12. The URL of the current tab is displayed to the user. ## Security and vulnerabilities They obtained a list of 295 publicly visible bugs with the "security" label in Chrome's bug tracker. Out of the 295 bugs, 42 cause denial-of-service such as a simple crash or 100% CPU utilization. They classified the remaining 175 bugs into the following seven. ![Browser vulnerabilities](https://i.imgur.com/tXppEBa.png) ## IBOS vs. SubOS vs. ChromeOS A number of recent papers have proposed new browser architectures. SubOS and ChromeOS run on top of commodity OSes and include complex libraries and window managers in their TCB. IBOS avoids this by focusing on the OS architecture. IBOS provides fine-grained protection for individual requests within a shared driver in addition to isolating the driver from the rest of the system. The driver security architecture in IBOS differs from these approaches. A number of recent projects have looked at reducing the TCB for window managers. IBOS deprecates the general window notion of modern computer systems in favor of the simpler browser chrome and tab motif.