This document describes the high-level security architecture of Chrome OS. It enumerates the principles the Chrome OS team uses to think about security, explains how these principles apply to different Chrome OS use cases, and outlines how these principles translate to security features in Chrome OS devices.
After going through this document the reader should be able to understand what threats Chrome OS aims to defend against, and how the system implements these defenses.
Chrome OS' main security goal is to protect user data and prevent devices from being compromised, while enabling users to operate their devices as they see fit. The team strives for usable security: providing users with a computing experience that achieves good security while being pleasant to use. To guide this work, the Chrome OS security team adheres to the following set of principles:
We believe these principles must apply to Chrome OS devices in all common use-cases, such as:
These use-cases inform several security requirements, among them:
Building secure computing experiences relies on defining a threat model, a description of the malicious actors we are trying to defend against, and their capabilities. We can describe attackers along different dimensions:
Presence: is the attacker remote, local, or do they have access to the inside of the device?
Targeting: is the attacker interested in a specific user or does the attacker not care about which users they're trying to compromise?
Attackers can also vary in their sophistication and resource availability: from a malware campaign that attempts to mine cryptocurrency on users' devices to targeted attacks from an oppressive government.
These dimensions combine into different personifications of attackers:
Given the use-cases Chrome OS enables, Chrome OS' main threat model is remote: Chrome OS protects against malicous webpages, and malicious or compromised Android apps, that attempt to take over the user's device or steal user data. These attacks can be opportunistic or targeted.
Notwithstanding our main remote threat model, user data protection is paramount in Chrome OS so the team also considers a subset of local/physically present threat models: device theft, and short-term opportunistic or dedicated physically-present attackers.
We specifically use the term “short-term” because a dedicated, resourceful adversary with unlimited physical access to a Chrome OS device is hard to defend against. Chrome OS can provide reasonable guarantees against user data extraction, but the attacker could completely replace the internals of the device with ones that are backdoored and there would be little Chrome OS could do against that.
The remainder of this whitepaper describes the defenses Chrome OS deploys against these attackers, what these defenses mean for users, and how we seek to fortify our defenses over time.
Figure 1: High-level view of the Chrome OS software stack.
As depicted in Figure 1, we will examine each of the layers of defenses Chrome OS deploys from the user's primary point of interaction (a browser accessing the web, an Android app, or a VM) to the device hardware. The principle of deploying defenses in depth is paramount here, as the layers of defense combine to provide a system more robust in its protection against threats.
The web presents a unique security scenario: accessing a web page via a browser amounts to executing untrusted code on a user‘s device. However, this code is being executed by a system (the web browser) which can take many steps to limit the privileges that untrusted code may hold. This limitation of privilege is an important security concept and key to Chrome OS’ approach to security.
The more privilege code executing on a device has, the greater potential for harm. Privilege, in this context, is the ability to access information or resources. The principle of least privilege calls for giving code only the privileges and permissions it needs to do its job, and nothing else. This is a general security principle and not specific to Chrome OS.
The Chrome browser approaches security the same way that Chrome OS does: by enforcing the principle of least privilege, deploying several layers of defense, and having fast, automatic updates.
The Chrome browser implements a multi-process architecture. This allows separating, in different operating system processes, the parts of the brower processing untrusted input, like a web page, and the parts of the browser accessing system resources or user data. This enforces the principle of least privilege by only giving web pages access to a very limited set of resources (drawing on a window, executing Javascript). A web page cannot directly access the user's files.
Web pages are loaded and executing inside a heavily-restricted runtime environment we call the Chrome sandbox. Chrome OS is Linux-based. Chrome on Chrome OS implements a Linux-based sandboxing environment inherited from Linux Chrome. Web pages loaded on Chrome OS Chrome have no access to the device's filesystem, nor to user files. Linux kernel namespaces ensure pages have no access to other processes on the system besides Chrome. Linux secure computing mode (seccomp) ensures pages have limited access to the operating system kernel.
Chrome OS follows Chrome's six-week release cycle, which allows for quickly delivering security fixes to users. Critical security bugs result in out-of-band releases that happen faster than every six weeks.
Chrome OS devices are intended to be both portable and safely shared. As a result, protection for user data stored on the local disk is a requirement for Chrome OS. This is accomplished via system-level encryption of all of the user's data. This also includes the entire Chrome browser profile so there is no risk of browser data leaking outside of encrypted storage.
Chrome OS uses ext4 encryption (using fscrypt) on newer devices, or the eCryptfs stacked filesystem (on older devices). In a nutshell, each user gets a unique “vault” directory and keyset that is created at their first login. The vault is used as the underlying encrypted storage for their data. The keyset is tied to their login credentials and is required to allow the system to both retrieve and store information in the vault. The vault is opened transparently to the user at login. On logout or reboot, the user's data is locked away again.
Chrome OS devices use a Trusted Platform Module (TPM) chip or an H1 security chip to protect against brute-force attempts to recover a user's keyset (and therefore the data it protects), and against attempts to directly extract the keys from the hardware.
Many Chrome OS devices, including tablets, support running Android applications. Android applications are executed inside a Linux container which restricts interactions with the rest of the system and access to user data. Moreover, Android applications are confined to the currently logged-in user session, which means that Android applications cannot be used to access information belonging to other users, nor to attack other user accounts. For devices managed by an organization, the ability to run Android applications can be disabled. Chrome OS does not allow Android application sideloading (except in a restricted developer case), so all Android applications installable on Chrome OS come from the Google Play Store and are covered by Google Play Protect.
The Android runtime in Chrome OS updates with the rest of Chrome OS, at least once every six weeks. Android has settled on a monthly cadence for releasing security patches. These patches are normally applied to Chrome OS when they're released publicly by the Android team. For critical issues the patches will be included in the next Chrome OS update released on the stable channel.
Chrome OS devices with sufficient storage and computing power may support running user-installed Linux applications. Linux applications are executed in a container running inside a hardware-based virtual machine. Chrome OS leverages the KVM Linux virtual machine solution with a Chrome OS specific virtual machine monitor written in the Rust language, which is memory and thread safe. This provides an effective security barrier between Linux applications and the Chrome OS system, without sharing the host Chrome OS kernel with the virtual machine guest.
This functionality provides a Linux environment, in effect a Linux “sandbox”, that is well isolated from the rest of the system and should allow executing untrusted workloads without exposing the main Chrome OS environment to these workloads.
Chrome OS enforces a hardware root-of-trust for the software running on the device. This means that the integrity and provenance of the software on the device are ensured by Google. This assurance is tied to the hardware on the device and cannot be subverted by purely software means. We call this Chrome OS' Verified boot.
What this means in terms of our threat model is that it should be impossible for a purely remote attacker to persistently modify Chrome OS system software in a way that's undetectable by our Verified boot stack. That is, any modifications to system software would be detected and corrected when the device is rebooted, or the device would refuse to boot.
An attacker needs to be physically present and have control of the device, and moreover needs to perform a hardware change to the device to be able to run untrusted code or code not coming from Google. And even in this case, user data remains safe because it is stored in an encrypted partition, specific to the user's account.
Bugs in this enforcement are rewarded as part of our vulnerability rewards program.
Chrome OS enforces a clear separation between the root or supervisor user in the underlying Linux system, and the operating system kernel. This is another case of enforcing the principle of least privilege. While the root user has wide-ranging powers in the system, there is no need for the root user to have as much privilege as the operating system kernel: there are things that the operating system kernel can do (like talking to hardware directly, or accessing certain CPU registers) that the root user does not need to do, at least not in an unrestricted way.
The Linux root user is also not exposed in the Chrome OS user interface, which means that Chrome OS does not have all-powerful (human) user accounts that would require this level of access to the system.
On Chrome OS, kernel module loading is restricted to modules loaded from the root partition covered by Verified boot. This means that while the root user can modify the kernel at runtime by loading kernel modules, these modules are still trusted code. Module loading from outside the verified root partition is disallowed. Chrome OS also restricts kernel functionality exposed to processes running as root using seccomp.
By enforcing the kernel/root barrier, we ensure that an attacker that attempts to compromise the kernel will need to exploit a kernel privilege escalation bug in addition to all the other bugs that they needed to exploit to obtain root code execution, making a kernel compromise less likely.
The Chrome OS team strives to provide a computing experience that's secure by default. That is, using a Chrome OS device to get things done, or browse the web, or run Android apps should not require the user to be a security expert. Importantly, Chrome OS deploys defenses against both persistent compromises (i.e. those which could survive a reboot of the device) and non-persistent compromises which exist only within an active session.
The Chrome browser in Chrome OS brings security features like renderer process sandboxing, Safe Browsing, and Site Isolation, which provide protections against non-persistent compromises: its harder for malicious webpages to compromise the OS. These features are enabled by default, and protect all Chrome users, including those on Chrome OS. For Chrome OS users, Verified boot means increased protection from persistent compromises: even in the unlikely case that a device is successfully attacked by a malicious webpage or potentially harmful application, all it takes to go back to a known-good state is a simple reboot: no need to reinstall anything. This makes Chrome OS devices significantly less suceptible to viruses and malware.
Chrome OS users can share the device with others without worrying that they will have access to your data: once you log out, your data is encrypted with a key tied to your password.
The ability of Chrome OS to enforce a known-good state for the software stack on a Chrome OS device simplifies the management of Chrome OS devices for organizations. The same features that ensure code integrity on a Chrome OS device for consumers ensure that a fleet of Chrome OS devices can be reliably managed.
The computing environment provided by Chrome OS, where the base software stack is verified on each boot, and software installation comes from curated sources (the Chrome Web Store and the Google Play Store) prevents users from installing software from untrusted sources. Chrome OS' approach is to be proactive rather than reactive: be strict about what software can run on the device, and have the operating system enforce this. With Chrome OS, endpoint integrity is provided by default.
Chrome OS implements the principle of defense in depth, where we deploy more than one layer of defense between untrusted content or code and sensitive data or device access. These layers define security boundaries. Bypasses of these boundaries are considered security bugs.
chronos) to system services: this boundary is traversed with D-Bus or Mojo. It should not be possible for the Chrome browser process to directly manipulate a system service or directly access system resources (e.g. firewall rules or USB devices). This is enforced by UID separation.Because no defense is ever perfect, we invite the broader security community to continually test our work. In particular, Chrome OS is part of the broader Google Vulnerability Rewards Program, which rewards external security researchers for finding and notifying Google of vulnerabilities.