Most current web browsers employ a monolithic architecture
that combines “the user” and “the web” into a single
protection domain. An attacker who exploits an arbitrary
code execution vulnerability in such a browser can steal sensitive
files or install malware. In this paper, we present the
security architecture of Chromium, the open-source browser
upon which Google Chrome is built. Chromium has two
modules in separate protection domains: a browser kernel,
which interacts with the operating system, and a rendering
engine, which runs with restricted privileges in a sandbox.
This architecture helps mitigate high-severity attacks without
sacrificing compatibility with existing web sites. We
define a threat model for browser exploits and evaluate how
the architecture would have mitigated past vulnerabilities.
Exploit mitigation in win32.
We investigate a new point in the design space of red/green systems [19,
30], which provide the user with a highly-protected, yet also highly-constrained trusted (“green”) environment for performing security-sensitive transactions, as well as a high-performance, general-purpose environment for all other (non-security-sensitive or “red”) applications. Through the design and implementation of the Lockdown architecture, we evaluate whether partitioning, rather than virtualizing, resources and devices can lead to better security or performance for red/-green systems. We also design a simple external interface to allow the user to securely learn which environment is active and easily switch between them. We find that partitioning offers a new tradeoff between security, performance, and usability. On the one hand, partitioning can improve the security of the “green” environment and the performance of the “red” environment (as compared with a virtualized solution). On the other hand, with current systems, partitioning makes switching between environments quite slow (13-31 seconds), which may prove intolerable to users.
Many of today’s web sites contain substantial amounts of
client-side code, and consequently, they act more like programs
than simple documents. This creates robustness and
performance challenges for web browsers. To give users a
robust and responsive platform, the browser must identify
program boundaries and provide isolation between them.
We provide three contributions in this paper. First, we
present abstractions of web programs and program instances,
and we show that these abstractions clarify how
browser components interact and how appropriate program
boundaries can be identified. Second, we identify backwards
compatibility tradeoffs that constrain how web content can
be divided into programs without disrupting existing web
sites. Third, we present a multi-process browser architecture
that isolates these web program instances from each other,
improving fault tolerance, resource management, and performance.
We discuss how this architecture is implemented in
Google Chrome, and we provide a quantitative performance
evaluation examining its benefits and costs.
This paper describes the design, implementation and evaluation
of Native Client, a sandbox for untrusted x86 native
code. Native Client aims to give browser-based applications
the computational performance of native applications without
compromising safety. Native Client uses software fault
isolation and a secure runtime to direct system interaction
and side effects through interfaces managed by Native
Client. Native Client provides operating system portability
for binary code while supporting performance-oriented features
generally absent from web application programming
environments, such as thread support, instruction set extensions
such as SSE, and use of compiler intrinsics and
hand-coded assembler. We combine these properties in an
open architecture that encourages community review and
Capsicum is a lightweight operating system capability and sandbox framework planned for inclusion in FreeBSD 9. Capsicum extends, rather than replaces, UNIX APIs, providing new kernel primitives (sandboxed capability mode and capabilities) and a userspace sandbox API. These tools support the compartmentalization of monolithic UNIX applications into logical applications. We demonstrate our approach by adapting core FreeBSD utilities and Google’s Chromium web browser to use Capsicum primitives, and compare the complexity and robustness of Capsicum with other sandboxing techniques.
Chrome OS uses a first stage read-only firmware and second-stage updatable firmware. The updatable firmware is signed and contains kernel keys and a dm-verify hash, so that the firmware, Linux kernel and root filesystem are all protected against corruption and attack. This system is described and discussed. As part of Google’s upstream efforts in U-Boot, a generalized secure boot system has been developed and released with U-Boot 2013.07. This implementation uses the FIT format, which collects together images, such as kernels, device tree, RAM disks. Support is provided for TPMs (Trust Platform Module), RSA-based signing and verificaiton, and hashing with hardware acceleration. This system is also described and discussed, along with the specific steps needed to implement it in your designs.