b134150b9f
This CL allows a sandbox broker (e.g. the chrome browser) to
provide a child process (e.g. a utility's main() function) an
opaque blob of data that is sourced from the sandbox delegate.
Up to one blob is allowed per-profile, and the blob can change
from one process launch to another (the blob is held on the
TargetProfile).
The blob is available in the child once TargetServices has
been initialized. The child can access the blob at any time
after that, but it is expected it will do so before calling
LowerToken().
This CL supports pre-loading DLLs in utilities. At this
point nothing uses the new facility.
Tests: sbox_integration_tests
Bug: 1435571
Change-Id: Ib68ca6dd2b792473e17af9abfca9f9038c7e8823
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4477653
Reviewed-by: Daniel Rubery <drubery@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1136667}
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.