ChildProcessSecurityPolicy

This directory contains Chromium's reference monitor for enforcing security policies, including Site Isolation, on renderer and other child processes. It is designed as a singleton in the browser process which grants permissions and access to origin data. These grants can be global for all Chromium processes or specific to a child process.

All sensitive operations performed on behalf of a child process must first consult ChildProcessSecurityPolicy to determine if the operation should be allowed. This includes access to origin data, local files, etc. Failed requests should usually result in a renderer kill, because they indicate a misbehaving or possibly compromised renderer process.

SecurityState tracks process-specific grants, ensuring that the state is kept alive as long as any requests may need it. This includes a period of time after the child process has exited, while IPCs or thread hops may be in flight. No new grants are allowed after the child process has exited, though.

ChildProcessSecurityPolicy is generally designed to be consulted from any thread in the browser process, using locks. However, some of its functions are only safe to call from specific threads (e.g., the UI thread) because of the parameters or state they need to access, as documented in the interface.

Migration to Rust

ChildProcessSecurityPolicy is being incrementally migrated from a C++ implementation to a Rust implementation in https://crbug.com/482216433.

This effort has multiple goals:

• Get experience with shipping first-party Rust code within Chromium's browser process, interacting with existing C++ code. This may clear a path for additional uses of Rust within Chromium.
• Improve safety invariants for a key security component in Chromium. Rust can more easily rule out classes of logic bugs at compile time. This is important for many invariants within ChildProcessSecurityPolicy (including how Site Isolation is enforced), as well as for reducing current stability problems in this code.
• Avoid any future memory safety concerns within ChildProcessSecurityPolicy, even if there are not currently a large number of memory safety issues known in this code.

ChildProcessSecurityPolicy is practical to migrate to Rust for multiple reasons:

• It has a clear API boundary with predominantly simple types. Most of its APIs take in IDs, strings, Origins, and FilePaths, and they return bools. It is primarily a set of data structures that can be populated and queried without complex pointer relationships.
• When Chromium C++ objects need to be passed to the Rust data structures, they can be owned by Rust. Non-owning pointers (which could pose safety risks) are generally not needed.
• It is a singleton, simplifying pointer ownership concerns.
• Most of the calls from Rust back into C++ in this code appear to be trivial and can likely be analyzed to be safe.

The migration is guarded behind the kChildProcessSecurityPolicyRust feature flag, which has multiple FeatureParams.

• kCppOnly: Only the C++ implementation of ChildProcessSecurityPolicy is used. This is the default if the feature is disabled, or via --disable-features=ChildProcessSecurityPolicyRust
• kRustOnly: Only the Rust implementation of ChildProcessSecurityPolicy is used. This is the default if the feature is enabled, or via --enable-features=ChildProcessSecurityPolicyRust
• kRustAndCpp: Both the C++ and Rust implementations of ChildProcessSecurityPolicy are used, and CHECK failures occur if the results differ. This mode can be enabled via --enable-features=ChildProcessSecurityPolicyRust:policy/rust-and-cpp All modes can be set via chrome://flags/#child-process-security-policy-rust.