[rust-dev] sandboxing Rust?

Patrick Walton pwalton at mozilla.com
Sun Jan 19 00:34:18 PST 2014


I think this is too strongly worded. While I agree that naively running untrusted Rust code is not a good idea at all, I think that language level security is not unachievable. It is absolutely an utmost priority to get to the point where the language is secure, and Rust treats memory safety issues with the same severity as security bugs. Even though we presently strongly advise against it, we intend to pretend that the point of Rust is to run untrusted code *as far as triaging issues and bugs is concerned*.

Emscripten/OdinMonkey and PNaCl have demonstrated that effectively hardening LLVM is possible for untrusted code. (Of course, there is a performance penalty for this.)

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.

Patrick

Daniel Micay <danielmicay at gmail.com> wrote:
>On Sat, Jan 18, 2014 at 10:30 PM, Scott Lawrence <bytbox at gmail.com>
>wrote:
>> On Sat, 18 Jan 2014, Corey Richardson wrote:
>>
>>> Rust's safety model is not intended to prevent untrusted code from
>>> doing evil things.
>>
>>
>> Doesn't it succesfully do that, though? Or at least with only a small
>amount
>> of extra logic? For example, suppose I accept, compile, and run
>arbitrary
>> rust code, with only the requirement that there be no "unsafe" blocks
>> (ignore for a moment the fact that libstd uses unsafe). Barring
>compiler
>> bugs, I think it's then guaranteed nothing bad can happen.
>
>Even a small subset of Rust hasn't been proven to be secure. It has
>plenty of soundness holes left in the unspoken specification. It will
>eventually provide a reasonable level of certainty that you aren't
>going to hit one of these issues just writing code, but it's not even
>there yet.
>
>> It seems to me that (as usual with languages like Rust) it's simply a
>mildly
>> arduous task of maintaining a parallel libstd implementation to be
>used for
>> sandboxing, which either lacks implementations for dangerous
>functionality,
>> or has them replaced with special versions that perform correct
>permissions
>> checking. That, coupled with forbidding unsafe blocks in submitted
>code,
>> should solve the problem.
>
>You'll need to start with an implementation of `rustc` and `LLVM` free
>of known exploitable issues. Once the known issues are all fixed, then
>you can start worrying about *really* securing them against an
>attacker who only needs to find a bug on one line of code in one
>poorly maintained LLVM pass. Even compiling untrusted code with LLVM
>without running it is a very scary prospect.
>
>> I could be completely wrong. (Is there some black magic I don't
>know?)
>
>Yes, you're completely wrong. This kind of thinking is dangerous and
>how we ended up in the mess where everyone is using ridiculously
>complex and totally insecure web browsers to run untrusted code
>without building a very simple trusted sandbox around it. Many known
>exploits been discovered every year, and countless ones kept private
>by entities like nation states and organized crime.
>
>The language isn't yet secure and the implementation is unlikely to
>ever be very secure. LLVM is certainly full of many known exploitable
>bugs and many more unknown ones. There are many known issues in
>`rustc` and the language too.
>
>I don't see much of a point in avoiding a process anyway. On Linux, it
>close to no overhead over a thread. Giving up shared memory is an
>obvious first step, and the process can be restricted to making
>`read`, `write` and `exit` system calls.
>
>The `chromium` sandbox isn't incredibly secure but it's not insane
>enough to even render from the same process as where it's compiling
>JavaScript. Intel open-source Linux driver is reaching the point where
>an untrusted process can be allowed to use it, but it's not there yet
>and any other video driver on any of the major operating systems is a
>joke.
>
>You're not going to get very far if you're not willing to start from
>process isolation, and then build real security on top of it. Anyway,
>the world doesn't need another Java applet.
>_______________________________________________
>Rust-dev mailing list
>Rust-dev at mozilla.org
>https://mail.mozilla.org/listinfo/rust-dev

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140119/c45be0bd/attachment.html>


More information about the Rust-dev mailing list