Sandbox/jail build scripts

[ishitatsuyuki]

Build scripts has too much capabilities than it would actually need. As a security measure, it may be good to perform some kind of sandboxing for them.

Things we could be restricting:

• Act as the nobody user, disallowing read of private files, or deletion of important files.
• Disable networking (with some way to opt out).

Strategy we could take:

• Just use some existing mechanism (changing user) to downgrade privileges. Is this possible?
• LD_PRELOAD and hook libc, which is what Gentoo use. Possible to bypass. Availability on Windows: possible, but probably harder than Linux.
• Full sandboxing with gVisor. Safe, but doesn't work for Windows indeed.

[joshtriplett]

Unfortunately, dropping privileges tends to require starting as root.

However, things like seccomp might help, though they're Linux-only.

[crepererum]

Depends. On Linux, you could use user namespaces (if they are enabled for that kernel) or helper tools like bubblewrap. Bazel also implements sandboxing (see this older blog post as well as this one). Firefox also implements different mechanisms on different systems to isolate certain processes. I think, this should be implemented by some sort of general purpose crate that then has OS-specific solutions. Worst case is that no sandboxing is implemented on your system (in which case cargo could print a warning.

[sam-ka]

We could take the setuid-helper approach here, where we ship a small binary that sandboxes the main cargo binary. I believe this is what Google does to sandbox Chrome and Electron on Linux.

[epage]

See also rust-lang/compiler-team#475

My ideal:

1. Allow opt-in full sandboxing of proc macros via wasm
2. Extend the system with capabilities requested via Cargo.toml for access to different system resources
3. Extend the system to build.rs

I see proc macros as the MVP for this because most can be "pure" (no external state or side effects) while build.rs inherently interacts with external state and has side effects.

[gdennie]

One possible way to control the scope of scripts is to require that their system access go through compiler provided precompiled libraries. These libraries may then respect configuration files and so forth to allow, deny, and log their effects. Additionally, these libraries can provide a great API into the build process itself while also making scripts both more powerful and quick to compile.

[CinchBlue]

My discussion for #13113 was redirected here. I just read rust-lang/compiler-team#475. It sounds like the WASI team is going for a file/directory-based directories interface...

2. Extend the system with capabilities requested via Cargo.toml for access to different system resources

...so it sounds like adding a [resources] section similar to [dependencies] for non-.rs source file resources would be useful for providing this "allowed" list.

[epage]

Just noticed rust-lang/rfcs#2794 which might be relevant