Capabilities and Rust

[Alan Karp]

There's a discussion on the Rust discussion board about the recent NPM issue in which somebody upgraded a widely used module to contain an attack.  There's lots of talk about sandboxes, so I introduced the idea of ocaps.  The objection is the amount of work that must be done to convert enough of the ecosystem.

I know Adrian Mettler implemented Joe-E for his Ph.D. thesis; Marc Stiegler did something similar for OCaml;  and Mark Miller and others are dragging the EcmaScript committee kicking and screaming in that direction.  So, how hard it is?  What's the least amount that needs to be converted to have a useful system?

--------------
Alan Karp

[Tony Arcieri]

On Wed, Nov 28, 2018 at 3:06 PM Alan Karp <alan...@gmail.com> wrote:

There's a discussion on the Rust discussion board about the recent NPM issue in which somebody upgraded a widely used module to contain an attack.

Where are you seeing this?

 

There's lots of talk about sandboxes, so I introduced the idea of ocaps.  The objection is the amount of work that must be done to convert enough of the ecosystem.

I know Adrian Mettler implemented Joe-E for his Ph.D. thesis; Marc Stiegler did something similar for OCaml;  and Mark Miller and others are dragging the EcmaScript committee kicking and screaming in that direction.  So, how hard it is?  What's the least amount that needs to be converted to have a useful system?

For Rust, I think the place to start is taming "unsafe". I would like to see something like a system for applying labels to unsafe functionality, possibly leaning on an existing mechanism like cargo features, to provide something roughly like the following:

- Crate "foo" exports unsafe functionality "fire_the_missiles", which using Cargo feature-esque syntax can be referred to as "foo/fire_the_missiles". You could imagine something ala adding a `#[label(fire_the_missiles)]` to the corresponding `unsafe` block/function.

- Crate "bar" consumes crate "foo", and vicariously invokes unsafe code "foo/fire_the_missiles" somewhere in its potential call graph

- Crate "baz" is consuming crate "bar" and wants to limit the unsafe code "bar" is allowed to vicariously call. In the Cargo.toml for crate "baz", when specifying its dependency for "bar", it could do something like the following:

[dependencies]

bar = { version = "1.2.3", allow_unsafe = ["foo/fire_the_missiles"] }

If crate "quux" were to consume crate "baz" and invoke functionality in "baz" which vicariously calls "bar" and in turn calls "foo/fire_the_missiles", it would likewise have to do:

[dependencies]

baz = { version = "0.1.2", allow_unsafe = ["bar/foo/fire_the_missiles"] }

While not strictly OCap, I think this provides something very much in the spirit of it: parent crates must explicitly grant the authority to call specific blocks of unsafe code, using a label which both names them and grants the authority to call them.

--

Tony Arcieri

[Mark Miller]

[resending MarcS's msg so it appears on both friam and cap-talk]

On Wed, Nov 28, 2018 at 3:25 PM Marc Stiegler <ma...@skyhunter.com> wrote:

I of course did the entire OCaml ocap system, including taming of the libraries, in 2 weeks over the Christmas holidays. Unsurprisingly, OCaml's library was both well designed for modularity and was also small. No UI. I disallowed using the Marshalling module which was all about zapping bits using pointers. I tamed the file system and the tcp/ip, sockets, etc. networking modules. Can't remember what else there was, but I tamed everything in the standard OCaml library. Java was of course another matter entirely. Months, probably 6. Of course that was the first taming effort ever by anyone, but I don't think that was really a big part of the problem, it was mainly the boundless vastness of Java's libraries. by and large the Java libraries were also well modularized, though you could tell that certain libraries were written by idiots, like the library implementing the global mutable keyboard. I later looked at the C# library, another enormous collection of stuff, and much less well designed than the Java libraries, it would probably take a man-year.

Rust had Brendan involved. Hard to believe it isn't well designed, and probably the core lib is small. So it could be 2 weeks to do it as well, like OCaml.

Converting code that already uses the untamed stuff is of course an entirely different matter. Completely indeterminable from here. the important lesson from both OCaml and Java is that, for the typical programmer doing typical things, the changes in what he needs to do to work with a tamed library are surprisingly limited. The difficulty in upgrading the programmers will surely be greater than the difficulty in upgrading the libraries, but not because there is either too much to learn or too great a change, it's just that programmers, like other humans, hate having to learn anything different. Of course, rust is young enough, maybe it's still early adopters who don't mind learning a new trick.

And of course the other thing we proved with OCaml is, there doesn't have to be a performance hit. Emily, the ocap version, generated executables that were, for many applications, just as fast as raw OCaml. Not surprising in retrospect: the things you care most about taming are the things involving i/o, which are already so slow a little indirection in the code is quite invisible.

--marcs

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To post to this group, send email to fr...@googlegroups.com.
Visit this group at https://groups.google.com/group/friam.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To post to this group, send email to fr...@googlegroups.com.
Visit this group at https://groups.google.com/group/friam.
For more options, visit https://groups.google.com/d/optout.

[Dan Connolly]

On Wed, Nov 28, 2018 at 5:43 PM Tony Arcieri <bas...@gmail.com> wrote:

[...]

For Rust, I think the place to start is taming "unsafe".

Really? That seems like the lowest bang-for-the buck that I can see. There's already a [forbid(unsafe_code)] mechanism and a reasonably strong sense in the community that it's a best practice (and tools such as https://crates.io/crates/cargo-geiger). Anything that uses unsafe or FFI is a lost cause, IMO.

The glimmer in the rust ecosystem is no_std. While the standard library uses the usual ambient authority idioms for file access etc., the no_std environment does not.

no_std was initially mostly for embedded stuff, but now there's webasm:

Crates that do not rely on the standard library tend to work well with WebAssembly.

fwiw, I have made a couple incomplete efforts:

• object capability discipline audit (WIP, FYI) #71 Nov 2016 - the app is called trust-dns, so I thought it ought to follow best practices. I started the audit and made one or two fixes, but the effort didn't "stick".
• Least Authority rust std/core libs Oct 2012 - toward taming the stdlib itself

As of early 2017, there was renewed interst inrefactoring std for ultimate portability. One result of this could be a std alternative with no ambient authority.

 

--

Dan Connolly

http://www.madmode.com/

[Bill Frantz]

Alan, my email didn't make it to cap-talk. Please forward.

--marcs

[Dan Connolly]

What about "eval"? To what extent would rust be a capability system without it?

One level of ocap system is one where you can't break the ocap discipline rules: memory safety, encapsulation, no ambient authority. But a system that does nothing trivially satisfies that.

Do we have a term for "rich capability system" or something? i.e. one where you can use mobile code to define arbitrary sharing policies?

[Tony Arcieri]

On Wed, Nov 28, 2018 at 5:25 PM Dan Connolly <dc...@madmode.com> wrote:

Really? That seems like the lowest bang-for-the buck that I can see.

On the contrary, I think it's the only logical place to start. Without memory safety, no other security protections (aside from ones provided by the kernel) can function, because unsafe is an escape hatch which can be used to bypass all other protections, rendering them all moot.

That's not to say those protections shouldn't be worked on in parallel (they could immediately be applied to, say, wasm environments), but unsafe really needs to be addressed for Rust to be a language where it's possible to run untrusted third party code safely.

 

There's already a [forbid(unsafe_code)] mechanism

...which isn't transitive (and notably the recent event-stream debacle involved a target attack via transitive dependencies). Any #[forbid(unsafe_code)] crate can call any other crate or std API which in turn calls unsafe, rendering it more of a crate-local lint than a bona fide security feature.

Furthermore, **there presently is no mechanism to ban unsafe code from dependencies**.

Don't get me wrong, I use #[forbid(unsafe_code)] as often as possible, or failing that #[deny(unsafe_code)], and have even designed [unsafe forbidden] badges people can display in their documentation, but I consider it a best practice, not a security feature.

 

and a reasonably strong sense in the community that it's a best practice (and tools such as https://crates.io/crates/cargo-geiger).

Again, to the contrary, I have personally found, even among the Rust Secure Code WG, that a push to use safe code and advertise things like #[forbid(unsafe_code)] or #[deny(unsafe_code)] to be surprisingly controversial. That said, I'm a fan of cargo-geiger, and generally try to push people to use safe crates over unsafe ones, but I don't see the community view as clear cut as you, even among people focusing specifically on security.

That said, even if there were overwhelming community sentiment that unsafe crates should be avoided, that's still not a replacement for first-class language features for controlling the usage of unsafe in dependencies.

--

Tony Arcieri

[David Teller]

If people are interested, one such discussion on (some form of) capabilities in Rust is now going on here.

[Will Sargent]

Also some talk about capability based apis in Rust (site seems to be down, so using archive.org): 

https://web.archive.org/web/20180129173236/http://zsck.co/writing/capability-based-apis.html

and

https://www.reddit.com/r/rust/comments/7rmgxo/using_capabilities_to_design_safer_more/

On Wed, Dec 12, 2018 at 8:14 AM David Teller <d.o.t...@gmail.com> wrote:

If people are interested, one such discussion on (some form of) capabilities in Rust is now going on here.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To post to this group, send email to cap-...@googlegroups.com.
Visit this group at https://groups.google.com/group/cap-talk.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/06b327ba-934e-4952-81b6-a7e704a77f11%40googlegroups.com.

[John Lee]

I just came across this blog post of Zack's independently and ended up at the same archive.org cache. I see on archive.org that he had a series of blog posts about capabilities and microservices, which now seem to be offline and not available on archive.org. Zack, if you're out there, I'd be interested to read what you wrote about that...

On Thu, 13 Dec 2018, at 22:50, Will Sargent wrote:
> Also some talk about capability based apis in Rust (site seems to be down,
> so using archive.org):
>
> https://web.archive.org/web/20180129173236/http://zsck.co/writing/capability-based-apis.html
>
> and
>
> https://www.reddit.com/r/rust/comments/7rmgxo/using_capabilities_to_design_safer_more/
>
> On Wed, Dec 12, 2018 at 8:14 AM David Teller <d.o.t...@gmail.com> wrote:
>
> > If people are interested, one such discussion on (some form of)
> > capabilities in Rust is now going on here

> > <https://internals.rust-lang.org/t/an-idea-to-mitigate-attacks-through-malicious-crates/9006>
> > .

> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "cap-talk" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to cap-talk+u...@googlegroups.com.
> > To post to this group, send email to cap-...@googlegroups.com.
> > Visit this group at https://groups.google.com/group/cap-talk.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/cap-talk/06b327ba-934e-4952-81b6-a7e704a77f11%40googlegroups.com

> > <https://groups.google.com/d/msgid/cap-talk/06b327ba-934e-4952-81b6-a7e704a77f11%40googlegroups.com?utm_medium=email&utm_source=footer>
> > .

> > For more options, visit https://groups.google.com/d/optout.
> >
>

> --
> You received this message because you are subscribed to the Google
> Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to cap-talk+u...@googlegroups.com.
> To post to this group, send email to cap-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/cap-talk.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/cap-talk/CAAvUidMUpRUe3HGk7ctky7UeTe4Z-d_mbrzWjYYYQeLBE05HJA%40mail.gmail.com.

[Grant Husbands]

In Zack's capabilities-in-Rust, wouldn't any library user be able to cast from any &Database to &CanSave<Comment>, thereby bypassing any semblance of object capabilities?

On Thursday, December 13, 2018 at 10:57:45 PM UTC, Will Sargent wrote:

Also some talk about capability based apis in Rust

[Grant Husbands]

There's now also a parallel discussion, here (started by myself and definitely not my most diplomatic work). I'd prefer full ocaps, but I'm only arguing for compile-time restriction of imports, there.

[Alan Karp]

I think the answer is taming, as described in https://people.eecs.berkeley.edu/~daw/papers/joe-e-ndss10.pdf.

--------------
Alan Karp

On Tue, Feb 5, 2019 at 6:28 AM Grant Husbands <grant.h...@gmail.com> wrote:

There's now also a parallel discussion, here (started by myself and definitely not my most diplomatic work). I'd prefer full ocaps, but I'm only arguing for compile-time restriction of imports, there.

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To post to this group, send email to cap-...@googlegroups.com.
Visit this group at https://groups.google.com/group/cap-talk.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/0e1c3d9a-05b5-463d-8f13-7063519e4ef6%40googlegroups.com.