Explore sandboxed build scripts

[nikomatsakis]

Metadata
Owner(s)	@weihanglo
Team(s)	cargo, compiler
Goal document	2024h2/sandboxed-build-script

Summary

Explore different strategies for sandboxing build script executions in Cargo.

Tasks and status

• [ ] Design (@weihanglo)
• [ ] Discussion and moral support (cargo )
• [ ] Security reviews ()
• [ ] Standard reviews (cargo )
• [ ] Collaboration with GSoC proc-macro project (compiler )
• [ ] Summary of experiments or RFC (@weihanglo)

[nikomatsakis]

This issue is intended for status updates only.

For general questions or comments, please contact the owner(s) directly.

[weihanglo]

Key developments:

Have been looking into different sandbox runtime choices. Here is a simple version of the comparison of three potential choices:

• eBPF
  • Required privilege
  • When installing: need other capability for like network monitoring CAP_PERFMON CAP_NET_ADMIN
  • When running: CAP_SYS_ADMIN or CAP_BPF for loading eBPF programs, unless unprivileged eBPF is enabled
  • Most Linux distributions don't allow unprivileged users to run eBPF programs.
  • Cross-platform
  • Linux: ✅
  • Windows: 🚧 https://github.com/microsoft/ebpf-for-windows
  • Darwin: ❓ https://www.reddit.com/r/eBPF/comments/y1whyh/plans_for_ebpf_on_macos/
  • Abilities
  • Process spawn: ✅
  • Network access: ✅
  • Filesystem access: ✅
  • How to use: leverage LLVM or any compiler to build eBPF bytecode
  • Security
  • Check capabilities when loading a eBPF program
• OCI spec compliant runtime
  • Required privilege
  • Cross-platform: ✅
  • Abilities
  • Process spawn: ✅ varies on different platforms
  • Network access: ✅ varies on different platforms
  • Filesystem access: ✅ via mounts in config.json
  • How to use: usually invoke a standalone binary (youki), but some are embeddable (northstar).
  • Security
  • Container technologies are based on system virtualization and isolation mechanisms, suchas cgropu or Hyper-V. These may bring large footprints (Can you imagine cargo run ubuntu:latest to run docker image!?), and is not really portable.
  • Well-defined (it has a specification!)
• WASI
  • Required privilege
  • Usually not required.
  • Cross-platform: ✅
  • Abilities
  • Process spawn: ❓ Unknown https://github.com/WebAssembly/WASI/issues/414.
  • Network access: 🚧 Phase 3 (implementation) https://github.com/WebAssembly/wasi-sockets
  • Filesystem access: 🚧 Phase 3 (implementation) https://github.com/WebAssembly/wasi-filesystem.
  • WASI is designed exactly for sandbox use cases.
  • Might not be configurable enough; it depends on runtime implementations and/or Wasi-libc. Usually permissions are granted via CLI options, for example wasmtime --dir.

There are prior research on cross-over between each of these options. I've been busy these two weeks. Will update a more detail post for prior arts afterward.

The biggest challenge I am seeing now is spawning external processes. Most build script usages invoke some external binaries, like pkg-config for building *-sys crates, or protoc for generating protobuf bindings. If process spawning is that common, we need to find a way to provide a fine-grained permission granting scheme. I don't want it to see an “all-or-nothing” mechanism when process spawning is needed.

The other huge headache is setting library search paths. We cannot know every possible path of system libraries ahead of time, but we need to grant access to the runtime.

Blockers:

None.

Help wanted:

None.

[weihanglo]

Having a family urgency. I will be back after RustConf.