0
Files
src/sandbox
Daniel Cheng fa0fad7735 Use absl::Cleanup for scoped execution in sandbox::policy::SandboxLinux
absl::Cleanup is a helper to run arbitrary code when the absl::Cleanup
object goes out of scope, which is useful for executing cleanup code or
ensuring something always runs. The current //base equivalent is
base::ScopedClosureRunner, which executes a base::OnceClosure when the
runner object goes out of scope.

Compared to base::ScopedClosureRunner, there are several benefits to
using absl::Cleanup:
- works with capturing lambdas, which are often much more concise than
  base::BindOnce()
- requires no heap allocations
- less impact on binary size since absl::Cleanup instantiates fewer
  templates

This CL is part of a project-wide cleanup to migrate to absl::Cleanup
where appropriate. The general criteria for migrating usages of
base::ScopedCLosureRunner:
- The cleanup scoper must not escape block scope, e.g. it is not
  returned from the function, passed to another function, or bound into
  a callback.
- The cleanup scoper's type does not need to be named, e.g. the scoper
  construction can use CTAD:
    absl::Cleanup run_at_exit = [] { RestoreSettings(original); };
  Note: having to write absl::Cleanup<decltype(lambda)> as a type is
  often a sign that absl::Cleanup is not a good fit for how the code is
  currently structured.
- The cleanup scoper is not simply running a base::OnceClosure.

Bug: 339492604
Change-Id: Ibfdfa88c0987b4559cbaeb0c42e259b46a842c90
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5528772
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Matthew Denton <mpdenton@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1298907}
2024-05-09 22:07:50 +00:00
..
2024-04-30 07:42:55 +00:00

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.