Compatibility risk is the risk that Apple changes the resources that a system framework accesses, causing Chromium’s sandbox to block the access.

Compatibility and Security RiskĬhromium‘s sandbox incurs two levels of risk which must be weighed: compatibility risk and security risk. The major difference under the V2 sandbox architecture is the removal of the unsandboxed warmup phase. The V2 sandbox continues to use the OS provided sandboxing framework and the “deny resource access by default” policy that the V1 sandbox used. By explicitly enumerating all resources in the sandbox profiles, it is possible to accurately audit Chromium's attack surface for each new macOS version.Īnyone wishing to know more about the macOS sandbox profile language should read the Apple Sandbox Guide from, or see the Appendix of this doc. This 2009 Chromium blog post explains that the warmup phase exists because it was unknown how to determine what resources those APIs used at the time. In the warm up phase, Chromium called system frameworks which acquired an unspecified number of resources before being sandboxed, and those resources change with every new OS update from Apple. This document also provides a high level overview of the macOS provided sandbox. This design doc provides a full implementation design and deployment strategy to sandbox the warmup phase. BackgroundĬhromium historically ran an unsandboxed warm up routine to acquire system resources, before entering the sandbox. To improve security on macOS by sandboxing the currently unsandboxed warmup phase of Chromium child processes, and to remove legacy artifacts in the sandbox profiles by rewriting them to use the most modern profile features. Status: Final, Authors: Last Updated: Objective

Apple sandbox os