I've been messing around with some ideas.
1. `autobox` (to be renamed lol) [0]. It's basically a Rust interpreter that performs taint and effect analysis, reporting on both, allowing you to use that information to generate sandboxes. ie: "autobox sees you used the string '~/.config' to read a file, and that is all the IO performed, so that is all the IO you get".
2. I'm working on a container based `cargo` with `riff` built in that aims to work for the vast majority of projects and sandbox your build with a defined threat model.
The goal is to be able to basically `alias cargo=cargo-sandboxed` and have the same experience but with a restricted container environment + better auditing of things happening in the container.
3. I previously built a POC of a `Sandbox.toml` and `Sandbox.lock` with a policy language that allowed you to specify a policy for a given build step. Unfortunately, I couldn't decide on how I wanted it to work in terms of "do I generate a single sandbox for the entire build, or do I run each build stage in its own sandbox" - there are tradeoffs for both.
Here's a lil snippet:
[build-permissions.file-system]
// All paths are relative to the project directory unless they start with `/`
"../" = {permissions = ["read"]}
// "$target" being a special path
"$target" = {permissions = ["read", "write"]}
// Source this path from the environment at build time, `optional` means it's
// ok if it isn't available
"$env::PROTOC_PATH" = {permissions = ["read", "execute"], optional=true}
// Default protobuf installation paths, via regex
"^(/usr)?/bin/protoc" = {permissions = ["read", "execute"], regex=true}
Once I'm done with (2) though I think I'll tackle (3).
`autobox` is fun but I think it may be impractical without more language level support and no matter what I'd end up having to implement it in the compiler at some point, which means it would be unusable without nightly or a fork.
I'm going to try to wrap up an autobox POC that handles branching and loops, publish it, and see if someone who does more compilery things is willing to pick it up. As for (2) and (3) I believe I can build practical implementations for both.
[0] https://github.com/insanitybit/autobox/