How the Chromium Broker Process Manages System Resources

In the Chromium web browser, security relies heavily on a multi-process architecture that isolates web content inside restricted environments known as sandboxes. Because these sandboxed "target" processes are stripped of their privileges to prevent malicious code from harming the host computer, they cannot directly request system resources from the operating system. Instead, they must rely on a privileged "broker" process. This article explains how the Chromium broker process acts as a secure gatekeeper, intercepting, validating, and executing system resource requests on behalf of restricted target processes.

Understanding the Target and the Broker

To understand how resources are managed, it is necessary to distinguish between the two types of processes involved in the sandbox architecture:

  • The Target Process: This is typically a renderer process (responsible for turning HTML, CSS, and JavaScript into a webpage) or a utility process. Because it handles untrusted web content, the operating system strips it of its privileges. It cannot read files, access the network, or interact with the user's hardware directly.
  • The Broker Process: This is the main browser process. It runs with the full privileges of the current user and exists outside the sandbox. For every one broker process, there are usually many target processes.

Step 1: Requesting a Resource via IPC

When a sandboxed target process needs a system resource—such as opening a local font file, allocating shared memory, or accessing the network—it cannot make a standard system call (syscall) to the operating system. If it tries, the operating system's kernel will immediately deny the request, or crash the process, due to the sandbox restrictions.

Instead, the target process must ask the broker for help. The target packages its request and sends it to the broker using Inter-Process Communication (IPC). In modern Chromium, this communication channel is managed by a system called Mojo. This IPC channel is the only lifeline the target process has to the outside world.

Step 2: Policy Evaluation

The broker process does not blindly fulfill every request it receives from a target. Doing so would defeat the purpose of the sandbox, as a compromised target process could simply ask the broker to delete system files or steal user data.

When the broker receives an IPC request for a resource, it passes the request through a built-in Policy Engine. The broker evaluates the request against a strict set of pre-defined security rules:

  • Is this specific type of target process allowed to make this request?
  • Is the resource being requested within an allowed directory or memory space?
  • Does the target need read-only access, or is it asking for dangerous write permissions?

If the request violates the security policy, the broker denies it and returns an error to the target process.

Step 3: Resource Acquisition and Handle Passing

If the Policy Engine approves the request, the broker process steps in as a proxy. Because the broker has full user privileges, it makes the actual system call to the operating system on the target's behalf.

Once the operating system grants the resource to the broker, the broker must transfer it to the target. It does this through a mechanism known as handle duplication (on Windows) or file descriptor passing (on Linux and macOS).

For example, if the target needs to read a specific file:

  1. The broker opens the file via the operating system.
  2. The operating system gives the broker a "handle" (a digital key) to that file.
  3. The broker duplicates this handle, restricts its permissions (e.g., ensuring it is read-only), and sends the duplicated handle back to the target over the IPC channel.
  4. The target process can now use that specific handle to read the file, even though it never had the authority to open the file on its own.

Summary of the Broker's Function

Ultimately, the function of the broker process is to enforce the Principle of Least Privilege. By stripping target processes of their rights to interact with the operating system, Chromium ensures that a compromised webpage cannot take over the computer. The broker acts as a translation layer and a security guard, ensuring that sandboxed processes receive the exact system resources they need to function, and nothing more.