[rust-dev] sandboxing Rust?

Daniel Micay danielmicay at gmail.com
Sun Jan 19 01:17:07 PST 2014


On Sun, Jan 19, 2014 at 3:34 AM, Patrick Walton <pwalton at mozilla.com> wrote:
>
> Emscripten/OdinMonkey and PNaCl have demonstrated that effectively hardening
> LLVM is possible for untrusted code. (Of course, there is a performance
> penalty for this.)

PNaCl is primarily a low-level sandboxing technology though. The
frontend languages/libraries, analysis/optimization passes, etc. do
not have to be correct. The scope of what they have to verify has been
drastically cut down to what is essentially a CPU architecture. I
think it's unlikely that the core implementation itself will have many
(if any) vulnerabilities. Once you throw in *all* of the Pepper API,
it's communicating with a huge codebase and loses the strong level of
security.

I don't think you can make a very strong claim that browser JavaScript
engines are secure sandboxes. There's an endless stream of *known*
security vulnerabilities for every major browser and the scope is far
too large. You can't trust a technology like that to be secure because
for every security researcher disclosing vulnerabilities, there are
many more being paid to keep it secret. The fact that vulnerabilities
are disclosed as a steady rate proves that browsers are totally
insecure.

> Finally, I disagree that processes are always the right solution here. If
> processes were as flexible as threads, there would be no need for threads!
> The trouble with isolation through processes is that isolation at the
> process level makes shared memory more difficult. For isolation with complex
> use of shared memory (mutexes and cvars), you really want language-level
> safety.

If there was a tiny subset of Rust it could be compiled down to with a
simpler backend (not LLVM), then I think you could talk seriously
about the language offering a secure sandbox. I don't think it is even
obtainable with a codebase as large as librustc/LLVM. A pretty high
number of issues in the Rust and LLVM trackers could be considered
security issues, and those are just the ones we know about.


More information about the Rust-dev mailing list