Comment by amluto
10 years ago
I mostly disagree. A sandbox like seccomp with a truly minimal set of system calls allowed through (read, write, close, exit) is a tiny attack surface and provides functionality roughly equivalent to raw Nacl. As far as I know, no holes have been found in seccomp configured like that. The problem isn't the sandbox per se, it's the set of services (3D! Audio! USB!) that are allowed through the sandbox. This proposal does nothing to help address that problem.
Exactly.
Every sandboxed app ever has needed native access of some sort to do something useful.
The best example of this difficulty is probably graphics (WebGL). To provide a compelling user experience, the API must allow apps to upload almost arbitrary code (shaders).
I'm genuinely curious what WebGL shaders can be used to do maliciously, and in what ways they can be considered arbitrary code?
They are arbitrary code, they just have to be written in GLSL. One of the vectors is the fact that less effort has been put into isolating and securing GPU memory, since previously, it was not considered sensitive. This is compounded by the fact that WebGL shader code and API calls are often processed by a layer with escalated privileges, written in C or C++, completely opaque, with lots of unknown bugs.
http://www.kitguru.net/gaming/security-software/carl/webgl-e...
http://www.contextis.com/resources/blog/webgl-more-webgl-sec...
http://www.pcworld.com/article/227438/dangerous_webgl_flaw_p...
3 replies →
The idea is that Rust (or something like it) is genuinely necessary to address it, because the necessary API is complex, as you say.
Rust does not write secure code.....
developers do...
... and they (might) use something like Rust... they could also (believe it or not) use C.
The problem with C to write secure software, it not only the set of language features for numeric, array and pointer manipulation that make it so easy to write exploits.
It is also the long set of compiler specific behaviors, sometimes version specific even, and UB. All of each very hard for a human to keep all the time on its head.
Hence why we have things like static analyzers, MISRA and Frama-C and still falls through the cracks.
Of course it's possible to write secure code in C, just as it's possible to write non-secure code in Rust. You can also drive a car at high speed with no seatbelts or airbags. If your code absolutely needs to be written in C, then do it, and do it carefully. If you're starting a new project and security is a concern, you ought to consider wearing a seatbelt.
Sure and you can build house out of anything, including Lego Blocks and Saltine Crackers. It's just that securing a brick house against rain is a lot easier than doing the same with house made of Saltine Crackers.
3 replies →
(safe) Rust allows developers the freedom to focus on logic, and not memory safety or undefined behavior. Being able to focus on just logic is why people have turned to memory safe languages for years. Rust finally does it with almost no runtime cost over that of C.
Even unsafe Rust offers more guarantees than C. But is a spot where you can remove the guard rails.
C was/is an amazingly performant language, but you're kidding yourself if you believe that most developers can write software as securely in it as they could in Rust.