Sandboxing

[RByers]

Description

A modern browser can only be made secure by relying on multiple processes (#3) and process sandboxing technology. Modern OSes like Windows, MacOS, Linux, Android and ChromeOS all provide the primitives that make a multi-process sandboxed browser possible, but iOS makes them available only to the system WebKit implementation. For details on existing browser design see Chromium Sandbox and Firefox Security/Sandbox. In addition to being essential in browsers, sandboxing technology is potentially helpful for securing any complex application that handles untrusted data (eg. messaging applications). There is an existing iOS API (NSExtension) for doing some of this, but it is private and so reserved for use by Apple only, such as in their Swift Playgrounds application. In 2021 Google made a feature request to Apple for a sandboxing API that would improve the security of Chrome, even when using Apple's WebKit engine.

Outcome

A secure browser needs at least the ability to set process security capabilities, eg. for chromium:

• enable/disable network access
• ability to write into shared graphics framebuffers and textures (IOSurfaces on MacOS/iOS)
• ability to access graphics APIs
• ability to access extended virtual address space (for PartitionAlloc) – currently the browser process needs an entitlement for this and we'd want the entitlement to carry over to spawned processes so that each, independently, has a large address space.

For maximum security, Chromium relies on a variety of process types. Details of Chromium's sandboxing system on MacOS can be found here and in the seatbelt files.

[RByers]

Note that BrowserEngineKit introduced 3-specific types of sandbox processes: WebContent, Networking and Rendering (GPU). It's not entirely clear exactly how those sandbox profiles are defined, but I suspect it comes from WebKit's own (evolving) definitions here. This seems like a very rigid and WebKit-specific approach to the problem of sandbox design.