Chromium Sandbox: Restricted Tokens and Job Objects

This article provides an overview of how the Chromium web browser implements its Windows sandbox using restricted tokens and job objects to severely limit the privileges of untrusted processes. By combining the access-control limitations of restricted tokens with the execution boundaries of Windows job objects, Chromium ensures that compromised rendering processes cannot interact with the underlying operating system, access user data, or spawn malicious child processes.

The Broker and Target Architecture

Chromium’s security model relies on a multi-process architecture divided into a "Broker" process (the main browser process) and "Target" processes (such as rendering engines and plugin hosts). The Broker runs with the user's standard privileges, while Targets run inside a strict sandbox. Because Target processes parse untrusted web content, Chromium assumes they will eventually be compromised. To prevent a compromised Target from harming the system, the Broker strips the Target of its abilities using Windows Restricted Tokens and Job Objects.

Limiting Securable Resources with Restricted Tokens

In Windows, every process has an access token that defines its security context, including the user's Security Identifiers (SIDs) and specific system privileges. When a process tries to access a securable object—such as a file, registry key, or another process—Windows checks the process's token against the object's Access Control List (ACL).

Chromium uses the Windows API to create a heavily modified, "restricted" token for its Target processes. It restricts the token in three primary ways:

  • Modifying SIDs to Deny-Only: Chromium converts the user's standard SIDs in the token into "Deny-Only" SIDs. This means Windows will only use these SIDs to deny access to resources, never to grant it.
  • Adding Restricting SIDs: Chromium adds a specific list of restricting SIDs (often just the NULL SID or a specialized "All Restricted" SID). When Windows evaluates access, both the standard SIDs and the restricting SIDs must be granted permission by the object's ACL. Because almost no system resources grant permissions to the NULL SID, access to the file system and registry is effectively blocked.
  • Stripping Privileges: Chromium removes all system privileges from the token, such as the ability to debug other processes (SeDebugPrivilege), shut down the system, or load device drivers.
  • Lowering Integrity Levels: The token is assigned an "Untrusted" or "Low" integrity level. Mandatory Integrity Control (MIC) in Windows ensures that a low-integrity process cannot write to or modify any resource with a higher integrity level, even if the ACL would otherwise allow it.

The Two-Token Lockdown Process

A completely restricted token is so locked down that the Windows OS cannot even start the process, because the process lacks the permissions to load core system DLLs from the disk.

To solve this, Chromium starts the Target process in a suspended state with two tokens. The primary token is the fully locked-down restricted token. However, the initial thread is given a slightly more permissive "impersonation" token. The process uses this impersonation token just long enough to load the necessary DLLs and initialize memory. Once initialization is complete, and before any untrusted web code is processed, the thread calls the RevertToSelf() API. This permanently drops the permissive impersonation token, locking the process into the completely restricted primary token for the rest of its lifecycle.

Containing Execution with Job Objects

While restricted tokens successfully block access to files, registry keys, and other processes, they only apply to securable objects—things in Windows that have ACLs. Windows has many system-wide functionalities and APIs that do not check security tokens at all. To secure these, Chromium places the Target process inside a Windows Job Object.

A Job Object is a kernel-level mechanism that allows the operating system to manage a group of processes as a single unit and enforce strict operational limits. Chromium configures the Job Object to enforce the following restrictions on Target processes:

  • No Child Processes: The job's active process limit is set to one. If a compromised renderer attempts to launch cmd.exe or powershell.exe, the operating system blocks the creation at the kernel level because the job limit has already been reached.
  • Clipboard Isolation: The job object explicitly revokes the process's ability to read from or write to the Windows clipboard, preventing malicious sites from stealing copied passwords or injecting malicious data.
  • UI and Display Restrictions: Windows allows processes on the same desktop to send messages to one another, which can be exploited to take control of higher-privileged applications (Shatter attacks). The Job Object blocks the Target from interacting with window handles outside of its own process, changing display settings, or accessing system parameters.
  • Resource Quotas: The Job Object places strict limits on memory and CPU usage. If a Target process attempts to execute a denial-of-service attack by exhausting system memory, the Job Object terminates the process before the wider operating system is affected.
  • Clean Termination: The job is configured so that if the main Broker process crashes or closes, the operating system automatically terminates all Target processes associated with the job, preventing orphaned, invisible processes from lingering in the background.

Summary of the Defense-in-Depth Approach

Neither mechanism is sufficient on its own. Without a restricted token, a process in a Job Object could still read the user's personal files. Without a Job Object, a process with a restricted token could still read the clipboard, exhaust system memory, or manipulate the user interface. By combining the ACL-based denials of Restricted Tokens with the kernel-level execution boundaries of Job Objects, Chromium creates a comprehensive sandbox that isolates untrusted web content from the Windows operating system.