Rust Once, Run Everywhere [LWN.net]

The Rust blog has posted a guide to using Rust's foreign function interface (FFI) with C code. Highlighted in particular are Rust's safe abstractions, which are said to impose no costs. "Most features in Rust tie into its core concept of ownership, and the FFI is no exception. When binding a C library in Rust you not only have the benefit of zero overhead, but you are also able to make it safer than C can! Bindings can leverage the ownership and borrowing principles in Rust to codify comments typically found in a C header about how its API should be used."

Unsafe Blocks

Posted Apr 27, 2015 5:40 UTC (Mon) by gmatht (subscriber, #58961) [Link] (11 responses)

It also seems that you don't need unsafe blocks when defining an interface to a new python library. Presumably this is the same for other safe languages. Nice, since if you don't really want unsafe blocks of code all over a "safe" implementation. It would be even nicer if Rust could constraint untrusted code blocks, but apparently this is a too big an ask.

Unsafe Blocks

Posted Apr 27, 2015 10:01 UTC (Mon) by ehiggs (guest, #90713) [Link] (10 responses)

"It also seems that you don't need unsafe blocks when defining an interface to a new python library."

Sure you don't need 'unsafe' in the interface, but if you look at the underlying code, large swathes of the implementation are marked 'unsafe'[1][2] for the obvious reasons.

"It would be even nicer if Rust could constraint untrusted code blocks, but apparently this is a too big an ask."

It would be nice, but it's probably orders of magnitude more difficult than offering a best effort at safety. And it would preclude the standard library from calling out to existing C libraries since they are all unsafe calls[3].

[1] https://github.com/lukemetz/rustpy/blob/master/src/base.rs
[2] https://github.com/lukemetz/rustpy/blob/master/src/ffi.rs
[3] e.g. std::num::f32::cos

Unsafe Blocks

Posted Apr 28, 2015 5:21 UTC (Tue) by gmatht (subscriber, #58961) [Link] (9 responses)

"large swathes of the implementation are marked 'unsafe'[1][2] for the obvious reasons."

Yes, that was the distinction I was trying to make. The first Python library you add means you add all the unsafe code in rustpy (and more importantly CPython). However, adding a *new* library does not require new new unsafe blocks. So wrapping n Python libraries needs O(1) unsafe blocks. Wrapping C instead requires O(n) unsafe blocks to wrap n libraries.

"And it would preclude the standard library from calling out to existing C libraries since they are all unsafe calls"

You could white-list some important presumed safe interfaces that use unsafe implementations. However, it would need a very strong definition of safe; even if you assume rustpy is bug-free you wouldn't want untrusted code calling the python file IO routines.

Being able to run untrusted code is the gold standard of a safe language. Reaching that point is very hard, but it is a bit of a sliding scale. For example, if you get a vendor supplied kernel driver written in Rust using some hypothetical Linus approved Rust API, and their programmer is obviously an idiot, should loading the driver taint the kernel? Or do we trust Rust to contain the stupid so that any problems are obviously the fault of the vendor? The line between evil and stupid can be come blurred, so we don't really trust the code not to be stupid/evil.

There does seem to be some support for getting Rust to the point where running untrusted Rust code is as (un)safe as running say untrusted JavaScript: https://mail.mozilla.org/pipermail/rust-dev/2014-January/...

Unsafe Blocks

Posted Apr 28, 2015 6:09 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Java tried to allow untrusted code (for applets) by using language-level isolation. We all know how well it went.

The same happened with Python's sandbox and pretty much everything else. The only surviving sandboxed languages are either very minimal (like lua) or use system-level isolation.

Unsafe Blocks

Posted Apr 28, 2015 9:37 UTC (Tue) by epa (subscriber, #39769) [Link] (5 responses)

Java tried to allow untrusted code (for applets) by using language-level isolation. We all know how well it went.

I thought it went okay? There were Java sandbox bugs but the record is surely better than Javascript, and a long way ahead of anything that doesn't use language isolation (ActiveX).

Java applets didn't take off because they were generally crappy in other respects, stuck in a fixed-size box, and could hardly interact with the surrounding web page - not because the security model was fundamentally broken.

Unsafe Blocks

Posted Apr 28, 2015 12:56 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> I thought it went okay?
Nope. There's an unending litany of bugs, mostly caused by some clueless developers leaving around publicly accessible (or ones that can be accessed with some care) privileged classes with functionality amounting to "sudo bash".

For example:
http://schierlm.users.sourceforge.net/TypeConfusion.html
http://krebsonsecurity.com/2015/01/java-patch-plugs-19-se...
...

> There were Java sandbox bugs but the record is surely better than Javascript, and a long way ahead of anything that doesn't use language isolation (ActiveX).
ActiveX has _no_ protection at all, so it's not a comparison at all. And JavaScript is generally more secure, because normally it has very few external access points.

Trusted Language Requirements

Posted Apr 29, 2015 3:14 UTC (Wed) by gmatht (subscriber, #58961) [Link] (2 responses)

There's an unending litany of bugs, mostly caused by some clueless developers leaving around publicly accessible (or ones that can be accessed with some care) privileged classes with functionality amounting to "sudo bash"

Agreed. For example, one bug was caused by starting a JMX server. That vulnerability was the first time I had heard of JMX servers. To secure a language (or anything else) you need to minimise the attack surface. The bytecode verifier used by Java seems basically OK now, but with Java the attack surface seems to be pretty much everything.

Avoiding ambient authority can reduce the attack surface. For example consider the following function prototype:

Bitmap image_decoder(const Bytes b);

Clearly image_decoder needs two special privileges: to read from b, and to return a Bitmap. The compiler obviously knows this, and can grant those privileges automatically. If we limited the ambient authority granted to all code to a few well thought out and important rights (say allocating memory [how much?] and writing to the log), then writing a malicious image_decoder would become a lot harder. If the image_decoder really needed to run start JMX servers we could alter the prototype to something like:

Bitmap image_decoder(const Bytes b, JMXFactory f);

Now the image_decoder could use the flaw in the JMXFactory to break out of its sandbox. But once the JMXFactory is fixed, the author couldn't just switch to using a flaw in the CORBA implementation (or whatever the whack-a-mole vulnerability of the day happens to be).

Trusted Language Requirements

Posted Apr 29, 2015 9:59 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

> Clearly image_decoder needs two special privileges: to read from b, and to return a Bitmap. The compiler obviously knows this, and can grant those privileges automatically. If we limited the ambient authority granted to all code to a few well thought out and important rights (say allocating memory [how much?] and writing to the log), then writing a malicious image_decoder would become a lot harder.
That's exactly what modern languages with effect typing systems do, see for instance Idris or DDC (disciple). Not the first time that functional languages show how it's done.

Trusted Language Requirements

Posted May 2, 2015 9:21 UTC (Sat) by roc (subscriber, #30627) [Link]

Until someone writes a big, complicated system in that sort of language, nothing really has been shown. It's easy to design a sophisticated type system that can prove amazing things about toy programs.

Unsafe Blocks

Posted Apr 30, 2015 10:16 UTC (Thu) by epa (subscriber, #39769) [Link]

Ah, you are referring to exploits using parts of the Java standard library which wrap unsafe code or buggy type casts. I agree, there is a lot of garbage in there. I would have expected applets or other sandboxed code to be restricted to a safe subset of the library, but apparently not.

I was thinking of Java the language, where admittedly there have been several bytecode verification bugs, but the core sandboxing model seems reasonably sound.

Of course, though, security depends not just on the theoretical model but on the quality of implementation all the way through the stack, and there Java falls short.

pysandbox vs pypy-sandbox

Posted Apr 29, 2015 3:26 UTC (Wed) by gmatht (subscriber, #58961) [Link] (1 responses)

I understand that pysandbox used a blacklist. Blacklists have a poor reputation even when not combined with local code execution, so I am not surprised the author gave up. Heck, Linux is designed to be reasonably secure for a monolithic kernel, rather than just layering a pysandbox-like hack on top. Yet, Linux has had a long list of security vulnerabilities. Folk wisdom seems to be not to trust the Linux Kernel's normal security model, and to contain any locally executed untrusted processes with something like SECCOMP.

What is your opinion of the security of the PyPy Sandbox model? I understand it uses a very short whitelist similar to SECCOMP. I haven't heard of any vulnerabilities, though that may just be because it is so new.

pysandbox vs pypy-sandbox

Posted Apr 29, 2015 3:29 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

PyPy sandbox might actually work. It completely isolates the running code from anything that might make syscalls or C-library calls. That's what Java sandbox _should_ have been from the start.

However, it still assumes that the language-level verifier and JIT do not have bugs and this might be a little bit overoptimistic assumption.