How Chromium Stops Renderers from Reading Host Files

Chromium utilizes a multi-layered security architecture to protect a user's local file system from malicious websites. Because the renderer process handles untrusted web content like HTML, CSS, and JavaScript, Chromium's security model assumes the renderer will eventually be compromised. This article provides an overview of the specific security boundaries—multi-process isolation, operating system sandboxes, Inter-Process Communication (IPC) brokering, and Site Isolation—that prevent a hijacked renderer from reading arbitrary files on the host disk.

1. The Multi-Process Architecture

The foundational boundary in Chromium is the separation of privileges across different processes. Chromium is divided primarily into a single, privileged "Browser" process and multiple unprivileged "Renderer" processes.

The Renderer process is responsible for parsing code and rendering the webpage, making it the primary target for attackers. Because of this risk, Chromium strips the Renderer of direct access to the underlying operating system. Only the main Browser process retains the privileges required to interact directly with the host's hardware, network, and file system.

2. Operating System Sandboxing

If an attacker successfully exploits a vulnerability in the V8 JavaScript engine or the Blink rendering engine to achieve Remote Code Execution (RCE), their malicious code is still trapped inside the Renderer process. To prevent this code from making direct system calls to the operating system to read files (such as calling open() or CreateFile()), Chromium relies on strict OS-level sandboxing.

Because every operating system handles permissions differently, Chromium uses platform-specific primitives to lock down the Renderer:

  • Windows: Chromium uses restricted tokens, Job objects, and AppContainer to strip the process of its security identifiers (SIDs). The Windows kernel actively denies any direct file system requests made by a process with this restricted token.
  • Linux: Chromium utilizes user namespaces, chroot, and seccomp-bpf (Secure Computing Mode). seccomp-bpf acts as a firewall for system calls; if a compromised renderer attempts to invoke a system call to open a file, the Linux kernel immediately blocks the action and terminates the process.
  • macOS: The browser uses the macOS Seatbelt (App Sandbox) mechanism, applying a strict profile to the Renderer that explicitly forbids file system read and write operations.
  • Android: Chromium leverages Android's isolatedProcess feature, which runs the renderer under a unique, unprivileged user ID (UID) enforced by SELinux policies that block access to local storage.

3. Mojo IPC and the Browser Broker

Because the OS sandbox blocks direct access to the disk, a Renderer must ask the privileged Browser process to fetch files on its behalf. This communication happens over Chromium's Inter-Process Communication (IPC) system, known as Mojo.

In this setup, the Browser process acts as a security broker. If a compromised Renderer attempts to trick the Browser process into reading an arbitrary file by sending a forged Mojo message, it hits another boundary: the ChildProcessSecurityPolicy.

The ChildProcessSecurityPolicy is a security object maintained inside the Browser process that tracks exactly what each Renderer process is allowed to access. By default, a Renderer has zero permission to read local files. The Browser process will only grant a Renderer permission to read a specific file if the user explicitly initiates the action through a trusted Browser-level UI element, such as an <input type="file"> dialog or a drag-and-drop event.

Because the file-picker UI runs in the privileged Browser process, the compromised Renderer cannot spoof a user selecting a file. When a file is legitimately selected, the Browser process updates the ChildProcessSecurityPolicy to grant that specific Renderer read access to only that specific file path. Any Mojo request from the Renderer to read a file not on its approved list is rejected by the Browser process.

4. Site Isolation

Site Isolation is a security boundary that ensures pages from different websites are always placed in separate Renderer processes, each locked to a single origin (domain).

Without Site Isolation, a compromised Renderer running evil.com could potentially share a process with a local file:// page or another web app that the user had previously granted file access to. By enforcing a strict one-site-per-process rule, Site Isolation ensures that the ChildProcessSecurityPolicy can accurately tie permissions to a specific origin. Furthermore, the Browser process blocks web-origin Renderers from ever navigating to or requesting file:// URLs, ensuring that local file exploration remains completely out of reach for web-based attackers.