The impact of memory safety on sandboxing · Alex Gaynor
Hi, I'm Alex. I'm a software resilience engineer. I care about building systems that work. I've worked for the government, in the private sector, and on open source. I'm based in Washington, DC.
Sandboxing and memory safety are generally considered two orthogonal, and therefore complementary, approaches to improving security. Memory safety reduces the likelihood of a vulnerability being introduced, and sandboxing reduces the impact if a vulnerability is exploited. However, I think this over-simplifies what sandboxing looks like in sophisticated multi-process architectures like web browsers and leads us to miss the potential implications of ubiquitous memory safety on sandboxing.
Sandboxing generally has two similar, yet distinct, purposes. The first is to reduce the semantic privileges a process has, and the second is to reduce the attack surface accessible to a process. These are abstract, so let’s consider some examples:
These seem similar, in that they reduce the post-sandboxed-code-execution vectors for an attacker, but they’re not! The former is enforcing the threat-model of our process: if websites aren’t supposed to be able to access the file system, then this makes that true even in the face of a code execution vulnerability. The latter, however, is to protect against the possibility that the kernel might have a vulnerability in its implementation of futex.
