Patrick Walton wrote:
On 7/11/12 10:09 AM, Ian Melven wrote:
Also, in general, i'm pretty curious about Servo's process model and
its security architecture,
maybe that's best discussed in a new thread though (I really need to
take some time
to understand Rust better as well). My particular interest is in how
Servo relates to the process sandboxing project I'm working on and
any ideas around what Servo's possible addon model might be -
Servo is often proposed as a solution to the needs driving the
sandboxing project but it seems
there will still be unsafe, possibly exploitable code in certain
parts of it.
The memory safety and type safety of Rust isn't a substitute for a
sandbox. Even with memory safety, it's still possible for someone to
call os::exec("calc.exe"). And it's still potentially possible to
exploit kernel32.dll, user32.dll, d3d9.dll, etc.
So we will need to use a sandbox. I think this sandboxing code should
be part of the Rust cargo ecosystem, so that Rust programs can
generally use it and the Rust community can contribute to it.
That said, memory safety definitely helps security in a big way. I
think of memory safety and type safety as just one particularly
powerful layer of protection. Just like any security layer, it rules
out many sources of exploits, but other layers of protection are needed.
Agreed, memory and type safety are big wins. But based on experience
with browsers, Java VMs, and the like, we probably need more.
The safety property called Control Flow Integrity [1] can be enforced
separately from Memory Safety, and it looks like useful belt-and-braces
on top of a memory-safe language and runtime due to inevitable low-level
bugs. CFI involves static code analysis and residual runtime checks to
ensure that all control flow transfers go where they should and nowhere
else.
The hard cases are calls and returns, especially virtual calls, since
Intel's lovely variable-length instructions enable ROP exploits.
Google Native Client [2] is a leading CFI-enforcing compiler and runtime
system. Anyone know of better? MSR had Xax [3] but it seems defunct.
I noticed https://github.com/mozilla/servo/issues/23 ("Explore ways of
integrating NaCl") get filed the other week. The main problem for NaCl
adoption (by any app other than Chrome and OS other than ChromeOS) is
its runtime API set, Pepper, which is large and unspecified -- rather,
implemented by a pile of chromium.org code. Pepper includes lots of
browser (WebKit + chromium) and OS abstraction, so it won't "port" to
Rust and Servo easily.
With NaCl, you theoretically can do without process isolation and rely
on the CFI enforcement, but last I checked, NaCl and Pepper in Chrome
still used process isolation in addition.
Unsafe native code is one issue, but bugs in the smaller TCB of the Rust
compiler and runtime that compromise CFI could still be exploited, fully
in our experience in Firefox and other Gecko/SpiderMonkey-based apps.
So I wonder whether, independent of what we do about enforcing CFI in
unsafe native code linked into Servo, we'll want to enforce CFI in the
Rust compiler and runtime. I don't think anyone has had time to look
into this, but it seems like a good research project.
/be
[1] http://research.microsoft.com/apps/pubs/default.aspx?id=64250
[2] http://code.google.com/p/nativeclient/
[3] http://research.microsoft.com/pubs/72878/xax-osdi08.pdf
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
