Open-sourcing gVisor, a sandboxed container runtime | Google Cloud Blog

Containers have revolutionized how we develop, package, and deploy applications. However, the system surface exposed to containers is broad enough that many security experts don’t recommend them for running untrusted or potentially malicious applications.

A growing desire to run more heterogenous and less trusted workloads has created a new interest in sandboxed containers—containers that help provide a secure isolation boundary between the host OS and the application running inside the container.

To that end, we’d like to introduce gVisor, a new kind of sandbox that helps provide secure isolation for containers, while being more lightweight than a virtual machine (VM). gVisor integrates with Docker and Kubernetes, making it simple and easy to run sandboxed containers in production environments.



The Security Architecture of the Chromium Browser

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.


Lockdown: Towards a Safe and Practical Architecture for Security Applications on Commodity Platforms

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.


Isolating Web Programs in Modern Browser Architectures

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.


Native Client: A Sandbox for Portable, Untrusted x86 Native Code

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
3rd-party tools.


Capsicum: practical capabilities for UNIX

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.