-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Determine project goals #3
Comments
I've opened an initial PR (#4) to propose gaol as the sandboxing mechanism. |
I am not sure where to post this, so I will just post it here. I think OpenBSD pledge is a well-designed approach. |
This is an initial example that will restrict cargo write access to its crate cache, the registry and the target directory using bubblewrap on Linux:
This may be improved depending on the objectives: for example, this does not constrain network access at all. |
@Siosm neat! That seems worth considering |
Here is an improved version that will (on top of previous example functionality):
One may use |
At a high-level, the goal of this project is to perform cargo builds inside of a sandboxed environment which restricts, to some extent, the capabilities of any code that executes at build-time.
A rationale for why this is valuable can be found in my Rust 2019 blog post: Security, Maturity, Stability
tl;dr: build-time attacks are stealthier than trojans in build targets, and permit lateral movement between projects when attacking a build system. The threat of a build-time trojan, versus a source code trojan, is an attack that does not leave behind forensic evidence and is therefore harder to investigate. Attacking a build system also potentially permits lateral movement between build targets.
That said, both the threat model and high-level design of this tool are debatable, and this issue is a place to discuss these matters.
Additional background:
The text was updated successfully, but these errors were encountered: