Security in ChromeOS

Introduction

This document describes the high-level security architecture of ChromeOS. It enumerates the principles the ChromeOS team uses to think about security, explains how these principles apply to different ChromeOS use cases, and outlines how these principles translate to security features in ChromeOS devices.

After going through this document the reader should be able to understand what threats ChromeOS aims to defend against, and how the system implements these defenses.

Principles of ChromeOS security

ChromeOS' 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 ChromeOS security team adheres to the following set of principles:

1. Deploy defenses in depth: Because no security solution is ever perfect, ChromeOS believes that we must deploy a variety of defenses to act as a series of bulwarks against an attacker. We make it difficult for an attacker to get into the system, but assume that an attacker may gain entry. We place additional layers of defense to minimize the amount of damage the attacker can cause after compromising the initial layer.
2. Make the system secure by default: A safe system is not an advanced or optional feature; it's the default for ChromeOS. All ChromeOS features are designed to minimize security risks so the user is generally not required to fully understand the security implications of using their device: the OS will just pick secure defaults. In particular, users should not need to make configuration changes to get a secure experience and we generally avoid providing settings that would allow users to inadvertently turn off security defenses.
3. Don't scapegoat our users: In real life, people assess their risk all the time. The web and Android app ecosystems are really a huge set of intertwined, semi-compatible implementations of overlapping standards. It is therefore difficult to properly assess risk in the face of such complexity, but this is not the users' fault. We work to design our user experience so that:
   • We can send the right signals to users, and keep them informed.
   • Users only get asked to make security decisions when there is no better alternative.
   • We ask for decisions in a way users comprehend.
   • We limit the impact of decisions, and make them revocable.
4. The perfect is the enemy of the good: No security solution is perfect, and the security landscape is ever-changing. Mistakes will be made, unforeseen interactions between complex systems may create security holes, and some vulnerabilities won't be caught by pre-release testing. ChromeOS does not allow the search for elusive “perfect security” to prevent developing and shipping meaningful security improvements now.

Common use-cases and security requirements

We believe these principles must apply to ChromeOS devices in all common use-cases, such as:

• Computing on the couch
• Computing at work or school
• Borrowing a device at a library or coffee shop
• Sharing a device among family members of all ages

These use-cases inform several security requirements, among them:

• The owner of the device should be able to share their device with users of their choice.
  • This means it's straightforward for a user to allow a co-worker, friend, or family member to use their device without compromising the user's security.
• A user should be able to manage their risk of data loss, even in the case of device loss or theft. This means two things for users:
  • First, it should be easy for users to utilize cloud storage and other services to have access to their data with high availability.
  • Second, even if the device is lost or stolen, it should be very difficult for another user to steal your data from the device without your login credentials.
• It should be trivial for the user to establish whether the operating system is trustworthy.
  • This means that ensuring a good security posture should be as simple as rebooting the device.
• Users should not have to worry about "patching" their systems for security bugs. Updates (including security updates) should be seamless.
  • This means that maintaining your security posture is simple: reboot and you're up-to-date. ChromeOS is designed to boot quickly, which helps ensure staying up-to-date isn't a burden for the user.
• TODO: Expand these.
  • Web pages and Android apps only have access to the resources the user allows.
  • Attackers can't access ChromeOS devices remotely.
  • Services users access from the device are isolated from each other.

How our principles inform the threat model

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?

  • A remote attacker can try to compromise the device by setting up a malicious webpage, publishing a malicious Android app, or manipulating data over the network.
    • Remote attackers cannot directly interact with the device but a subset of them will be in close enough proximity to it (e.g. in the same room as the ChromeOS user) to allow exploiting bugs in RF device firmware (like WiFi or Bluetooth chips).
  • A local attacker can interact with the device: connect a malicious USB stick, attempt to log in, reboot the device, or just steal the device altogether.
  • A local attacker with unbounded, unsupervised access to the device and enough technical skill can disassemble the device, and modify or replace software or hardware. At the limit this attacker is hard to defend against because a modified device with entirely new electronics but the same case would leave nothing for ChromeOS to enforce, but might still be undetected by the user.

• Targeting: is the attacker interested in a specific user or does the attacker not care about which users they're trying to compromise?

  • An opportunistic adversary is an attacker who is trying to compromise any user's device or data, without care for which user or organization controls the device. This attacker's motivation is usually economic, so an opportunistic adversary is likely to deploy attacks which attempt to lure users to websites or apps which:
    • Compromise the user's device (e.g. to mine cryptocurrency, or deploy a ransomware attack).
    • Steal user data (to obtain credit card details, or extort the user with personal information).
  • A dedicated adversary is an attacker that may target a specific user or organization. A dedicated adversary may steal a device to recover account credentials or data, as opposed to simply selling a stolen device for money. The intention is generally to harm the targeted user or organization. A dedicated adversary may deploy DNS or other network-level attacks to subvert a user's attempt to login (i.e. deploy a phishing attack) or update their device. A dedicated adversary is assumed to do anything an opportunistic adversary may do. Defense against an opportunistic adversary can aid in defense from a dedicated adversary, but cannot be considered complete.

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:

• A nosy roommate is a local/physically present, but likely opportunistic and not very sophisticated attacker. They might try a few common passwords on the user's device.
• An abusive partner is a local/physically present but targeted attacker. They might still not be very sophisticated but would be highly motivated.
• A thief is a physically present attacker who's more likely than not to be opportunistic (but could be targeted as part of an operation from an intelligence agency or oppresive government).
• An online malware or ransomware campaign is a remote attacker, likely opportunistic and with varying levels of sophistication. Their motivation would usually be economic.
• An intelligence agency or oppressive government can be a remote or local, but targeted and likely sophisticated attacker.

Given the use-cases ChromeOS enables, ChromeOS' main threat model is remote: ChromeOS protects against malicious 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 ChromeOS 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 ChromeOS device is hard to defend against. ChromeOS 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 ChromeOS could do against that.

The remainder of this whitepaper describes the defenses ChromeOS deploys against these attackers, what these defenses mean for users, and how we seek to fortify our defenses over time.

Layers of ChromeOS security

Figure 1: High-level view of the ChromeOS software stack.

As depicted in Figure 1, we will examine each of the layers of defenses ChromeOS 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.

Security and the Web

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 ChromeOS' approach to security.

The principle of least privilege

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 ChromeOS.

Security in the Chrome browser

The Chrome browser approaches security the same way that ChromeOS 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 browser 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. ChromeOS is Linux-based. Chrome on ChromeOS implements a Linux-based sandboxing environment inherited from Linux Chrome. Web pages loaded on ChromeOS 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.

ChromeOS 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.

Going beyond the browser

Protecting user data

ChromeOS 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 ChromeOS. 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.

ChromeOS 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.

ChromeOS 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.

Android apps and ChromeOS

Many ChromeOS 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. ChromeOS does not allow Android application sideloading (except in a restricted developer case), so all Android applications installable on ChromeOS come from the Google Play Store and are covered by Google Play Protect.

The Android runtime in ChromeOS updates with the rest of ChromeOS, at least once every six weeks. Android has settled on a monthly cadence for releasing security patches. These patches are normally applied to ChromeOS when they're released publicly by the Android team. For critical issues the patches will be included in the next ChromeOS update released on the stable channel.

Linux applications and ChromeOS

ChromeOS 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. ChromeOS leverages the KVM Linux virtual machine solution with a ChromeOS 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 ChromeOS system, without sharing the host ChromeOS 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 ChromeOS environment to these workloads.

Hardware root-of-trust and Verified boot

ChromeOS 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 ChromeOS' 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 ChromeOS 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.

Root versus the OS kernel

ChromeOS 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 ChromeOS user interface, which means that ChromeOS does not have all-powerful (human) user accounts that would require this level of access to the system.

On ChromeOS, 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. ChromeOS 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.

What ChromeOS security means for you

What ChromeOS security means for users

The ChromeOS team strives to provide a computing experience that's secure by default. That is, using a ChromeOS device to get things done, or browse the web, or run Android apps should not require the user to be a security expert. Importantly, ChromeOS 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 ChromeOS 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 ChromeOS. For ChromeOS 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 ChromeOS devices significantly less suceptible to viruses and malware.

ChromeOS 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.

What ChromeOS security means for organizations

The ability of ChromeOS to enforce a known-good state for the software stack on a ChromeOS device simplifies the management of ChromeOS devices for organizations. The same features that ensure code integrity on a ChromeOS device for consumers ensure that a fleet of ChromeOS devices can be reliably managed.

The computing environment provided by ChromeOS, 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. ChromeOS' 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 ChromeOS, endpoint integrity is provided by default.

Security boundaries

ChromeOS 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.

• Chrome renderer process to Chrome browser process: this boundary is traversed only with Chrome IPC or Mojo. It should not be trivial for a Chrome renderer process to directly manipulate or control the Chrome browser process or the rest of the system. This is enforced by the Chrome sandbox.
• Chrome browser process (running as user 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.
• ARC++ container to Chrome browser or ChromeOS system: this boundary is traversed with Mojo IPC. It should not be possible for the container to directly manipulate resources outside of the container. Trust decisions should always be made outside of the container.
• Userspace processes to kernel: this boundary is traversed by system calls. It should not be possible for userspace to gain untrusted kernel code execution (this includes loading untrusted kernel modules). Seccomp is used to secure this boundary.
• Kernel to firmware: it should not be possible for a kernel compromise to result in persistent, undetectable firmware manipulation. This is enforced by Verified boot.

Vulnerability rewards program

Because no defense is ever perfect, we invite the broader security community to continually test our work. In particular, ChromeOS is part of the broader Google Vulnerability Rewards Program, which rewards external security researchers for finding and notifying Google of vulnerabilities.