| commit | f3f872ac512e813655692dfad3a43eab17867b50 | [log] [tgz] |
|---|---|---|
| author | Stefan Smolen <ssmole@microsoft.com> | Wed Nov 03 22:39:39 2021 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Nov 03 22:51:30 2021 |
| tree | a74d924936f0cf8969b484ccded7c5fa0da8d280 | |
| parent | 896ad8cca627e913e5469c3d2463c1fa97bcd157 [diff] |
Add null DACL test on desktop security descriptor when creating alt desktop My investigation uncovered that the reason our utility processes fail to load user32.dll (and crash) is because loading user32.dll requires access to the desktop that the process is started on, and the sandbox desktop's SD (security descriptor) does not allow access to anything. The SD is based on the SD of the desktop the browser process is running on, which can be a desktop created by third party software. If this desktop's SD has a null DACL, it will have access to everything, but when we create the sandbox desktop based it we combine the existing DACL with the sandbox restrictions, which nets a DACL that only has restrictions and doesn't allow access to anything. This change detects the case where we are basing the sandbox desktop SD on a null DACL, and adds an ACE that allows Everyone (WinWorldSid) and all AppContainers (WinBuiltinAnyPackageSid) access to anything (GENERIC_ALL) before the sandbox restrictions are applied. Bug: 1252987 Change-Id: Id3409f3d1ddee8e4409f60d27fe3317ee499e97e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3258421 Commit-Queue: Stefan Smolen <ssmole@microsoft.com> Reviewed-by: James Forshaw <forshaw@chromium.org> Cr-Commit-Position: refs/heads/main@{#938045} NOKEYCHECK=True GitOrigin-RevId: b8cd461e6b01bb9fd813019efdf0ddc8a0356aff
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.