Build-time sandboxing

[tarcieri]

There's been a lot of discussion in the WG (and in the past, several pre-RFC style proposals) to add some sort of sandboxing around code executed during the build process, including things like build.rs files and procedural macros.

I wrote down my rationale for what I'd like to defend against with such a sandbox:

https://tonyarcieri.com/rust-in-2019-security-maturity-stability#sandboxing-for-code-classprettyprintbuildrsco_2

tl;dr: build-time attacks are stealthier than trojans in build targets, and permit lateral movement between projects when attacking a build system.

The devil is in the details, though. This issue is for discussing them.

Some prior art / discussion:

• pre-RFC: Cargo Safety Rails
• RFC: Implement a sandbox for environment variables and files
• Security fence for crates
• Build script capabilities

[tarcieri]

In broad strokes, I think there are two paths to be pursued, which are not mutually exclusive and also do not depend on each other and therefore can be independently pursued by anyone interested:

1. "Do No Harm" sandbox: retrofit sandboxing in such a way that it does not break any existing crates, e.g. add sandboxing which does not break crater. This severely limits what can be sandboxed, but also means we can turn it on for everyone today.
2. "Ambitious" sandbox: off-by-default sandboxing, but where we can explore stricter restrictions which would be bigger wins. These would be things like restricting network access, filesystem access, and things like seccomp policies or running all builds under gaol.

Regarding number 2, what I think would be nice is for crates to opt into a more restrictive sandbox initially, then make that sandbox the default for the next Rust edition (with the ability to opt out). Then in the next edition after that, make it mandatory.

[ckaran]

"Ambitious" sandbox: off-by-default sandboxing, but where we can explore stricter restrictions which would be bigger wins. These would be things like restricting network access, filesystem access, and things like seccomp policies or running all builds under gaol.

I like/prefer this approach. The hard problem is determining what should/shouldn't be allowed. I propose that we create an 'underhanded rust' competition similar to the underhanded C competition. I don't think we need to go to the extent of actually writing code, at least not until someone starts writing a real sandbox, but it would be a good way to look for bugs in ideas. If we set up a wiki or other permanent area where all the ideas that are generated are gathered, then we can start figuring out what a real sandbox implementation will need (and what it will need to defend against).

[tarcieri]

The hard problem is determining what should/shouldn't be allowed.

For this sort of approach, I think it might be nice to start with the most restrictive sandbox that makes sense, and allow crate consumers to opt into the special permissions some crates might need to do unusual things at build time.

Here's a longer writeup of that idea: https://internals.rust-lang.org/t/build-script-capabilities/8635

[Shnatsel]

underhanded Rust

https://underhanded.rs

1. "Do no harm"
2. "Ambitious"

Why not both?

[ckaran]

@Shnatsel And that is why I should google more and talk less...

[tarcieri]

Why not both?

I think both are potentially valuable. To be clear this isn't necessarily an either-or decision.

[tarcieri]

Interestingly enough, it looks like crater now forbids network access: rust-lang-nursery/crater#336

[ckaran]

FYI, there is a tracking issue that might be of interest to others reading this thread.

[Shnatsel]

Do we have a threat model defined? I don't think we could move forward very effectively without one.

[tarcieri]

@Shnatsel I wrote up a bit about that in my blog post:

• Build scripts / proc macros allow attackers to move laterally between low value and high value targets
• They also permit stealthy attacks, whereas trojan payloads in targets leave forensic evidence

Now, the above isn't universally true of course. Some people don't have low vs high value targets. Some people do builds in virtual machines or isolated clusters so as to avoid lateral movement. The extent to which these threats can be addressed by other means than adding a compile-time sandbox to Rust is certainly debatable.

[Shnatsel]

I.e. we assume that a dependency that's pulled in is malicious or compromised?

[tarcieri]

Yes, this all presumes an attacker has published a malicious crate and a victim has consumed it

[ckaran]

Would Docker or LXC be a good way to mitigate the compile-time problems? My thought is that the rust community shouldn't reinvent the wheel; if at all possible, we should reuse whatever security methods are available to us.

[tarcieri]

@ckaran personally I already do containerized builds using Docker. I agree that mitigates a lot of the same problems, and that Rust shouldn't reinvent Docker, but not everyone is using containerized builds, and even then I'd prefer a "belt and suspenders" approach.

[ckaran]

@tarcieri I agree about the 'belt and suspenders' approach, but I was thinking of what could be done to mitigate issues quickly. One method would be to make docker/LXC/something else containers be the standard; when you install rust, you get the containerized versions.

Once that is done, we've got a little breathing room and can consider what to do next properly, rather than stomping out fires if they come up.

[tarcieri]

I don't think containers make sense for that. It's great if they're part of an (existing) build system, but a containerization environment is an extremely heavyweight dependency to require for Rust itself.

I think something like gaol, as a lightweight, self-contained Rust library (and one which the core team is already somewhat familiar with, I'd wager) designed specifically for the purposes of sandboxing, would make more sense:

https://github.com/servo/gaol

[ckaran]

@tarcieri Gaol is a good idea, but as the project states on its own page "At the moment, gaol is only lightly reviewed for correctness and security. It should not be considered mature or "battle-tested". Use at your own risk." Given that, I figure that it might be better to get something that plugs the hole now, and then replace it with something better when that something (gaol, or something else) improves to the point that it can be used instead.

[tarcieri]

I suspect making Docker, runc, or any sort of containerization tool a mandatory dependency of Rust is going to be a nonstarter.

[ckaran]

OK, so how do you suggest we proceed? Use gaol (or something similar) ASAP, and fix bugs as they come up? While I accept that gaol is the better approach, my concern is one of time; it may be quite a long while before gaol is considered to be as good as the current available containerization technologies. How do we deal with any problems that crop up between now and then?

[tarcieri]

I think we're at the point we can attempt a prototype (perhaps an experimental out-of-tree one). I think that's something @alex expressed interest in.

I can provide a writeup of the sort of thing I'd like to see.

[kpcyrd]

If I recall correctly gaol requires special privileges that a regular user doesn't have. Restricting certain syscalls with seccomp is probably the best way forward.

[tarcieri]

gaol allows you to configure a profile regarding which kinds of sandboxing you'd like performed and also detect whether that type of sandboxing is applicable to the current platform.

I'm not sure which of its sandboxing features require elevated privileges, but if they exist, we can shut them off for non-superusers, and enable them for superusers. This is particularly helpful as it's quite common for builds to run as root. If anything, I would like to see that functionality leveraged in those scenarios.

One of the many things gaol does is configure Linux seccomp policies, so if that's what people would like to see, we could start there with a gaol profile.

[zachreizner]

Jotting this idea down that we came up with on the zulip channel:
If we don't want sandboxed build scripts to have networking, but we do want to support the use case of downloading a native source dependency that is missing (such as zlib or openssl), one potential solution would be to have optional "sidecar" zips that include the necessary source. If the build script determines that it needs it, it signals this to cargo which will download a whitelisted zip from crates.io.

[tarcieri]

@zachreizner what makes a "sidecar zip" different from publishing the same contents as a crate?

[zachreizner]

The difference is that most crate content is not optional, where as this explicitly would be. That being said the idea of "sidecar zip" could be implemented using existing crate mechanisms.

[tarcieri]

Yeah, I think leaning on crates as the archive format is the way to go. Potentially multi-stage builds could be used to e.g. run a script to determine of the next stage needs those optional resources, potentially enabling them as cargo features, which are the existing conditional compilation mechanism for selectively downloading crate dependencies.