Thread by @LeaKissner

"THE LIMITS OF SANDBOXING AND NEXT STEPS" from Chris Palmer at #enigma2021

usenix.org/conference/eni…

This talk is going to go through the experience pushing the boundaries on sandboxing in the Chrome browser

What is sandboxing?
* breaking something into lower/higher privileged process
* necessary for browers, OSes, VMs etc.

Chromium uses to reduce the amount of privilege of the application: also to reduce the amount of privilege for code that touches websites (renderer)
* split different websites into different processes
* good defense against logic bugs (e.g. same-origin policy)

Good sandboxing is table stakes..
* necessary to contain a variety of classes of bugs, leaks, and vulnerabilities.
* not, by itself, sufficient for Chromium, nor arbitrarily applicable.

We’re pretty sure Chromium is near the practical limit…
...but your application might still have significant sandboxing headroom left. Use it!

The fundamental building block available to us is the process boundary.
* Fault isolation
* System call filtering
* Low-privilege principals (UID/GID, SID, Access Tokens)
* Segmented memory someday…?

OS mechanisms (Android)
* isolatedProcesses
* Medium-grained system call filtering (certain predefined Seccomp-BPF policies)
* SELinux

OS mechanisms (Linux, Chrome OS)
* Fine-grained system call filtering (freer use of Seccomp-BPF)
* User/PID/network namespaces
* Legacy setuid helper where namespaces not available

But can't sandbox everything (or at a fine-enough grain)!
* Process space overhead: Large on Windows, very large on Android
* Process startup latency: High on Windows, very high on Android

How do we decide when to create a new renderer process?
* Site isolation: one process per renderer (more or less) to keep different sites apart
* ... plus GPU
* ... plus network
* ... plus storage

Moving forward: memory safety [hey, a theme in the session!]
* Sandboxing isn't enough: still significant browser, kernel, kernel attack surface available
* Need to not just contain bugs, but to mitigate and hopefully even solve them.

Investigating safer language options
* Java/Kotlin on Android
* Swift on iOS/macOS
* Rust
* WebAssembly?

Migrating to memory-safe languages:
* Not all-or-nothing! Thankfully!
* We can focus on hot spots: areas of particularly large, soft, or easily-accessible attack surface.
* Interoperability and overall complexity are huge concerns.
* Learning curve, too.

Improving memory-unsafe languages
* Smarter pointer types (MiraclePtr)
* Garbage collection (expanding the use of Oilpan) and semi-GC (MiracleScan)
* Defining undefined behavior
* New hardware features (memory tagging, control flow integrity)

We need to get to the "acceptance" stage as Alex describes [see last talk thread]

Chromium High+ severity vulns breakdown [diagram]

Platform security teams throughout industry — including Microsoft, Android, and Apple — are seeing same problems we are: about ⅔ to ¾ of security-relevant bugs are due to memory unsafety

All seem to be looking in the same direction for solutions: further reduce privilege, increase memory safety.

Create significant asymmetries that favor defense — attackers are less able to get what they want with a single bug (need a chain of bugs), vulns harder to find+exploit

The future
* Sandboxing has given Chromium 10+ good years!
* The next 10 require something more: memory safety

[end of talk]