On 2/13/13 9:43 PM, Robert O'Callahan wrote:
(Of course a big sandbox around the entire browser, or independent browsing contexts, could still be useful as a second line of defense to prevent the system from being persistently corrupted in case of a Rust exploit.)
That's exactly the purpose. Mostly the threat model I'm concerned with consists of these three vectors:
(1) An exploit in OS-supplied native code that we can't control. We don't control graphics drivers (and even if we proxied all GL calls they could be attacked remotely), and on Windows in particular you have to bring kernel32.dll into your address space to talk to the kernel at all.
(2) An exploit in our safe wrappers for OS native code. For example, we might incorrectly wrap a Windows COM object, causing it to be freed early and a subsequent dereference of the vtable would cause an exploitable security vulnerability.
(3) An exploit of a logic error in the safe Rust code. For example, someone might trick the download manager into saving a file to C:\Windows\System32 without user permission.
Sandboxing can provide an additional line of defense against all of these issues. There is also the chance that the Rust implementation or type system has exploitable bugs, which sandboxing helps with too.
The memory safety guarantees that the Rust compiler provides vastly reduce the surface area of vulnerabilities, of course, and I think the engine will be much stronger for that. I think the various Chromium exploits have demonstrated that sandboxing is not enough; we need to make sure that every virtual call added to the browser isn't a potential exploit waiting to happen, and that's what the Rust type system is designed to protect against.
Patrick _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
