Add an explanation for why access to cfsprefsd is denied

This is denied by our general default policy, but since it generates
sandbox reports when sandbox logging is enabled it's helpful to have a
record of which denials are intentionally denied rather than yet to be

This section will be fleshed out further as I have time to investigate
the other intentional denials.

Change-Id: Id3e0ac9a55df498e1fc92d3c3c597d753f083756
Reviewed-by: Robert Sesek <>
Auto-Submit: Mark Rowe <>
Commit-Queue: Robert Sesek <>
Cr-Commit-Position: refs/heads/main@{#1144391}
GitOrigin-RevId: b4529b6fc93ad8473fe379cd1a5c936c232f95e6
1 file changed
tree: f8c1aa12348fc1102e6eb4261eab8eca3ff6ed52
  1. linux/
  2. mac/
  3. policy/
  4. win/
  7. constants.h
  8. DEPS
  11. features.gni
  12. features.h
  13. OWNERS
  15. sandbox_export.h

Sandbox Library

This directory contains platform-specific sandboxing libraries. Sandboxing is a technique that can improve the security of an application by separating untrustworthy code (or code that handles untrustworthy data) and restricting its privileges and capabilities.

Each platform relies on the operating system's process primitive to isolate code into distinct security principals, and platform-specific technologies are used to implement the privilege reduction. At a high-level:

  • mac/ uses the Seatbelt sandbox. See the detailed design for more.
  • linux/ uses namespaces and Seccomp-BPF. See the detailed design for more.
  • win/ uses a combination of restricted tokens, distinct job objects, alternate desktops, and integrity levels. See the detailed design for more.

Built on top of the low-level sandboxing library is the //sandbox/policy component, which provides concrete policies and helper utilities for sandboxing specific Chromium processes and services. The core sandbox library cannot depend on the policy component.