[Technical Initiative Funding Request]: Cross-platform sandboxing of build processes

[wolfv]

Technical Initiative

Securing Software Repositories

Lifecycle Phase

graduated

Funding amount

66400 Euro

Problem Statement

We want to build a cross-platform sandbox that can be universally used by package build programs

Who does this affect?

Any package manager that cares about hermetic, isolated, trustable and sandboxed build processes

Have there been previous attempts to resolve the problem?

There are partial solutions to this problem used by Nix, Bazel, and other projects. To our knowledge, no one has produced a unified approach that also covers Windows.

Why should it be tackled now and by this TI?

We need to secure open source repositories, and packages and make builds more reproducible and easily sandboxed.

Give an idea of what is required to make the funding initiative happen

There are many projects that isolate processes – however, most are OS specific. During our extensive research we could not find any project that offered an easy to use sandbox for Windows, macOS and Linux - which is the aim of this project.

We would like to build a Rust library / binary that can be used to start an arbitrary process in a sandbox. The sandbox should be able to:

• restrict access to the files on the host operating system (such that the process cannot see the files in the home folder of the user, for example). Additionally, the sandboxed process should not be able to write to any files outside the ones it is explicitly allowed to.
• restrict access to the network, and allowing no access or access only to specific IPs / Domains.

What is going to be needed to deliver this funding initiative?

We would like to build a new Rust project that wraps a standard std::process::Command interface with sandboxing options. There are already a number of existing libraries out there and we could look at them for inspiration or consider contributing to one of them.

We already did a deep-dive into sandboxing on Windows, and the AppJail technology was determined as suitable. There are a few hoops that we will have to jump through in order to be able to offer a unified interface for users. Additionally, the AppJail technology is relatively sparsely documented by Microsoft and there is not much reference code found on e.g. Github. However, we had initial prototypes that showed that it is feasible to build powerful sandboxing on top of this technology.

The goal of this funding is to provide a versatile, well maintained, and well positioned Rust crate that can be used in any ecosystem (NPM, Nix, Cargo, Conda, pip/PyPI ...) for hermetically sandboxing build processes on all major operating systems (Windows, macOS and Linux). Beyond sandboxing build processes, we are also interested in sandboxing applications and scripts that are untrusted and that users may want to run.

Are there tools or tech that still need to be produced to facilitate the funding initiative?

Yes, we would build a new Rust library with an estimated ~3 - 5000 lines of code.

Give a summary of the requirements that contextualize the costs of the funding initiative

The main cost of this work are software development cost.

Who is responsible for doing the work of this funding initiative?

Wolf Vollprecht, prefix.dev GmbH

Who is accountable for doing the work of this funding initiative?

Wolf Vollprecht

If the responsible or accountable parties are no longer available, what is the backup contact or plan?

Other people at prefix.dev GmbH

What license is this funding initiative being used under?

BSD-3

Code of Conduct

• [x] I agree to follow the OpenSSF's Code of Conduct

List the major milestones by date and identify the overall timeline within which the technical initiative plans to accomplish their goals. Any payments for services, sponsorships, etc., will require LF Legal and Financial review.

6 months after funding we would like to have a an early version of this library out on crates.io 9 months after funding we would like to have documentation and extensive test suite done. 12 months after funding we would like to have a 1.0 released that can be used in established projects.

If this is a request for funding to issue a contract, then OpenSSF will issue that contract. Please provide a Statement of Work (SOW) that we may review. Any contracting action will take 4-6 weeks to issue.

SOW OpenSSF sandboxing __ prefix.dev.pdf

[JLLeitschuh]

Doesn't AnyRun do this? Couldn't that work for this use case? https://any.run

They support Linux, Android, and Windows

[wolfv]

Thanks for the comment @JLLeitschuh - any.run doesn't look open source to me. We want maximum distribution of this library / sandbox and ideally it would be integrated in a wide variety of tools (from NPM / Nix / Cargo / ...) - which will be very hard if the tool is not open source & free.

[JLLeitschuh]

Ah, I misunderstood the use case. This isn't for malware analysis, this is for defense. Sorry for my misunderstanding

[steiza]

/vote

[git-vote[bot]]

Vote created

@steiza has called for a vote on [Technical Initiative Funding Request]: Cross-platform sandboxing of build processes (#473).

The members of the following teams have binding votes:

Team
@ossf/tac

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 14days. It will pass if at least 55% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

[bobcallaway]

I have a couple questions:

1. Do we have any package registries committed to deploying this yet?
2. What is the longer term maintenance story for this library?
3. What OSS license would you be proposing this code to be offered under, and do you envision this being part of an upstream foundation?

[wolfv]

Hi @bobcallaway, thanks for your questions!

1. We don't have any package registries that are committed to deploying this yet. We would definitely want to use this in our build tool (rattler-build) as well as in our package manager (pixi) and other tools that may emerge for the Conda ecosystem. I also heard from Nix people that they would like to have a sandboxing solution for Windows to support the Nix on Windows efforts - however, I cannot make any firm statements whether they would use it or not. We have a good track record though with resolvo (our SAT solver) to build software that is re-usable in different ecosystems (Debian and TCL have written plugins or package managers that use resolvo)
2. and 3. We would choose a liberal open source license and usually use BSD-3 (but also open to e.g. Apache-2 + MIT which is commonly used in the Rust world). The longer term maintenance would be carried out by us and other users of the library - usually, after the initial investment the maintenance becomes a lower effort that we are more than happy to fund indefinitely.

[steiza]

I think I'm a "no" on this proposal (for now, not "no, not ever").

This is a very cool technical capability, but it's sort of one degree removed from actually landing a security improvement in a package repository. My opinion is that we want proposals to be more concrete in landing a security improvement.

What I'd like to see in an iteration on this proposal (possibly for future funding cycles) is engagement from a specific package repository, as well as how the sandboxing would be used in that repository.

[mlieberman85]

I agree with @steiza on this one. I like the idea, but it really isn't tied to an existing TI's work right now. I'd like to see this maybe be tied to something like SLSA and what they're doing with their tooling. I'd also like to see some pre-work done maybe in a white paper to highlight where the gaps are. Or if that work has already been done to be linked here.

[mlinksva]

I'm just a bystander and naive fan of sandboxing everything but thought I'd point out some possibly relevant work or interest in multi platform sandboxing for Rust and Swift builds in case helpful for a future iteration on this or other proposal in the same direction.

Rust 2024 goal that hasn't carried over to 2025 but the issue comment at the second link and above has lots of analysis and potential future directions.

SwiftPM is another package manager that hints of interest in sandboxed build (plugins) with support across multiple platforms:

Every plugin runs as a separate process, and (on platforms that support sandboxing) it is wrapped in a sandbox that prevents network access as well as attempts to write to arbitrary locations in the file system.

As far as I can tell only macOS sandboxing is supported but there are references to internal Apple tracking of support for two other platforms, presumably Linux and Windows.

[git-vote[bot]]

Vote status

So far 0.00% of the users with binding vote are in favor and 22.22% are against (passing threshold: 55%).

Summary

In favor	Against	Abstain	Not voted
0	2	0	7

Binding votes (2)

User	Vote	Timestamp
steiza	Against	2025-04-24 18:51:09.0 +00:00:00
mlieberman85	Against	2025-04-24 22:47:26.0 +00:00:00
@justaugustus	Pending
@scovetta	Pending
@bobcallaway	Pending
@lehors	Pending
@gkunz	Pending
@marcelamelara	Pending
@camaleon2016	Pending

[wolfv]

Thanks for the feedback and no worries if this turns out as a no.

I genuinely think that if we nail this, it can be one of the highest impact security improvements for all package managers. Not only during build-time but also during execution time of packages downloaded from the internet. I would love to make that happen for all the ecosystems I am involved with (Conda, PyPI, ...) and I am totally convinced that a lot of other package managers would jump on the bandwagon if a nice cross-platform solution existed (thanks @mlinksva for producing more evidence for this claim!).

But it's not a simple feat, and also happy to wait it out till the next round.

[marcelamelara]

Thanks for submitting this request @wolfv ! I think we need this sort of tool, personally, and I share many of the concerns other TAC members have pointed out, regarding buy-in from package repos or a connection to other TIs. Specifically, while this project is being requested under the umbrella of Securing Software Repos WG, it's not clear that this work has actually been discussed with the WG, so I'm not comfortable approving this funding request.

Has this project been presented at any of the OpenSSF working groups or projects yet? Besides the Securing Package Repositories WG, I agree that this work may be of interest to the SLSA project or the Supply Chain Integrity WG. I highly recommend trying to engage more with the community and (possibly) starting with the project lifecycle, because I do believe that sandboxing of build processes is a worthwhile endeavor.

[wolfv]

Yes, I've been joining a few calls here and there and I've also tried to pitch this to Michael Winser for Alpha Omega. Personally I don't care under what specific working group this falls and I am more than happy to engage with anyone on this matter. I would just really love this work to get done :)

[camaleon2016]

I agree with @steiza I don't see the security element in this aside from sandboxing. Also, the timetable is a bit long.

[gkunz]

Not doubt about the importance of tooling for securing the build environment and process - so I do think this fits into the OpenSSF's scope. As mentioned above by @mlieberman85, investigating how to align this with SLSA would be great to ensure it fits well. In terms of a gaps analysis, I'd be interested in comparing the pros and cons of this solution from a package repo perspective to other solution, such as containerized builds.

[wolfv]

@gkunz how can you do containerized builds for non-linux platforms? :) (aside from cross-compilation)...

[gkunz]

@gkunz how can you do containerized builds for non-linux platforms? :) (aside from cross-compilation)...

yeah, right... well, it would not be an extensive comparison then 🙃

[git-vote[bot]]

Vote closed

The vote did not pass.

0.00% of the users with binding vote were in favor and 77.78% were against (passing threshold: 55%).

Summary

In favor	Against	Abstain	Not voted
0	7	0	2

Binding votes (7)

User	Vote	Timestamp
@marcelamelara	Against	2025-04-28 16:06:54.0 +00:00:00
@bobcallaway	Against	2025-04-30 12:43:14.0 +00:00:00
@lehors	Against	2025-04-28 13:34:45.0 +00:00:00
@steiza	Against	2025-04-24 18:51:09.0 +00:00:00
@mlieberman85	Against	2025-04-24 22:47:26.0 +00:00:00
@camaleon2016	Against	2025-04-29 11:27:30.0 +00:00:00
@scovetta	Against	2025-04-29 15:14:56.0 +00:00:00

[kj-powell]

Closing this as it id not pass TAC vote