HomeLog InSource


[View] [Short] [Hash] [Raw]


What is a sandbox?

A hypervisor is not a sandbox. A sandbox might run inside a hypervisor.

People talk about the “browser sandbox” or the “Lua sandbox” or the “Xen sandbox” but none of those things are sandboxes. A sandbox has no features and lets you do nothing you couldn’t do already.

A sandbox uses an API to implement that same API. Securely, of course.

The core of a sandbox is a specification of a safe subset of an API. It then either blocks unsafe calls.

Formal proof of the sandbox code and specification is only one part of its security. Because the underlying implementation is assumed to be buggy, a sandbox needs to be adaptable as bugs and workarounds are discovered.

A sandbox can mitigate this risk by being conservative in what APIs it relies on. The output of a MOV-only compiler is unlikely to be affected by any CPU bugs.

Once you have a sandbox providing a useful subset of an API, you might be able to emulate the full API using only that subset. That emulation isn’t the sandbox, or part of it, but they are often paired together.

Something that actually is a sandbox is a network firewall. Of course, port 80 is a hole you can drive a truck through. The emulator is the proxy you use to get useful work done despite everything being blocked.

Another sandbox is the NaCl verifier. It’s already been updated to remove CLFLUSH due to RowHammer. The emulator is the compiler they supply.

Now let’s look back at the browser and try to see what sandboxes it has. One immediate example is the same-origin policy. However SOP is slightly weird in that it doesn’t protect the user or the website in question; it’s intended to protect other websites. Perhaps those poor incentives are why it was never fixed when cross-site request forgery (CSRF) was discovered.

There’s some sort of policy against using the hard drive, but it’s ill-defined. You’re allowed to use it as an SQL database (WebSQL) or for tracking (supercookies), but there’s no definite limit on what directories you can write to or how much data you can store.

But my biggest complaint is that all of the APIs within the sandbox are different from those used to implement it. We seem to be unable to sandbox without making up new interfaces at the same time. We wouldn’t need WebSQL if we had a file-system sandbox we could run SQLite on top of.

I can think of a few reasons. First, it’s hard to (ahem) draw lines in the sand without specific use cases in mind. So we start by adding APIs for microphone and webcam, and then later decide that’s not good enough and add WebUSB.

Second, because most of the underlying APIs are grown rather than designed. They’re huge and complicated and every application uses a disjoint subset.

Relatedly, there are a dearth of vendor-neutral APIs to choose from. On the web, portability is a big concern, so the primary focus is on developing new APIs that are equally inconvenient for everyone. When defining those APIs, security gets thrown in as an afterthought.

A familiar API makes it look too easy to implement. If I give you a path of a file to open, you might just pass it to open(2) without any sanitization (look at how many web servers have had that problem). A convoluted API that doesn’t even let me express paths makes those obvious errors impossible (even if it makes subtle errors more likely).

And finally, what I think is the ultimate reason: security just isn’t much of a priority. It’s hard to justify software that gets in your way sometimes and doesn’t let you do anything new.