| commit | b3267c8b40b6133b2db5475caed8f6722837a95e | [log] [tgz] |
|---|---|---|
| author | Matthew Denton <mpdenton@chromium.org> | Wed Jul 21 12:55:11 2021 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Jul 21 13:06:05 2021 |
| tree | 2653f0db1d2fa637c261448de95212b94c7d4e0d | |
| parent | 2c1640200247e444677ab5dd261a15543bcfbe66 [diff] |
Linux sandbox: fix fstatat() crash This is a reland of https://crrev.com/c/2801873. Glibc has started rewriting fstat(fd, stat_buf) to fstatat(fd, "", stat_buf, AT_EMPTY_PATH). This works because when AT_EMPTY_PATH is specified, and the second argument is an empty string, then fstatat just performs an fstat on fd like normal. Unfortunately, fstatat() also allows stat-ing arbitrary pathnames like with fstatat(AT_FDCWD, "/i/am/a/file", stat_buf, 0); The baseline policy needs to prevent this usage of fstatat() since it doesn't allow access to arbitrary pathnames. Sadly, if the second argument is not an empty string, AT_EMPTY_PATH is simply ignored by current kernels. This means fstatat() is completely unsandboxable with seccomp, since we *need* to verify that the second argument is the empty string, but we can't dereference pointers in seccomp (due to limitations of BPF, and the difficulty of addressing these limitations due to TOCTOU issues). So, this CL Traps (raises a SIGSYS via seccomp) on any fstatat syscall. The signal handler, which runs in the sandboxed process, checks for AT_EMPTY_PATH and the empty string, and then rewrites any applicable fstatat() back into the old-style fstat(). Bug: 1164975 Change-Id: I3df6c04c0d781eb1f181d707ccaaead779337291 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3042179 Reviewed-by: Robert Sesek <rsesek@chromium.org> Commit-Queue: Matthew Denton <mpdenton@chromium.org> Cr-Commit-Position: refs/heads/master@{#903873} NOKEYCHECK=True GitOrigin-RevId: 60d5e803ef2a4874d29799b638754152285e0ed9
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.