5 ms·

It would be nice to see some sort of sandboxing for these. I would love it if cargo had a mechanism to run all build actions for a crate inside a firecracker vm

It would be nice to see some sort of sandboxing for these. I would love it if cargo had a mechanism to run all build actions for a crate inside a firecracker vm. That said, most build systems can access everything the user has access to, so it's not really a regression from the industry standard. And Rust's typesystem on its own isn't enough to protect against malicious crates, even if you ban all unsafe code, procedural macros, build.rs, and filesystem/network APIs. Several soundness issues were found in previous versions of the standard library that allow a malicious crate to take advantage of undefined behavior to run arbitrary machine code. It seems likely to me that there are similar unknown issues lurking in today's standard library or compiler. If you care about security, you have to audit your dependencies very carefully, no matter what language you are using.

bitwize 3y ago
If you're not sandboxing, you're asking to get pwned.
goku12 3y ago
> I would love it if cargo had a mechanism to run all build actions for a crate inside a firecracker vm Why not go in the other direction? A tool that can set up a VM with source code and build tools based on a declarative file? That could work for any language - not just Rust. Sort of like a completely local CI system.
- oneshtein 3y ago
  Who will verify VM, your local CI, and produced binary?
  - goku12 3y ago
    The idea of the microVM is to isolate the build system from the host. Your question is beyond the scope of the original problem.
- remram 3y ago
  You're describing Vagrant.
  - goku12 3y ago
    Ah! You're right. I wonder if vagrant is enough to mitigate these concerns.
zer8k 3y ago
> If you care about security, you have to audit your dependencies very carefully The problem is Cargo is yet another iteration of the npm-ization (maven-ization?) of code. It requires a BDFL or a team of such BDFLs to proactively police the repos in order to prevent trivial supply chain attacks. Your statement misses the point that not only do people NOT do this it's now trivial to avoid it with Cargo. This is not the same security risk that is present if you use git submodules and build with a makefile. The key difference is ease of use. Cargo, like NPM and to some extent Maven, are so easy to use you've accidentally created a massive attack surface. The result will likely be yet another incarnation of JFrog or the like. Code will be audited, built into dylibs, and then pinned via some enterprise supply chain manager. This is a big lift for companies who might otherwise switch to Rust for new projects quicker. Cargo is my main gripe with Rust almost all the time. So many people say "you can just build manually with rustc!" but this is not true. It's not as simple. Again, it would also be one thing if Cargo was just the package manager but it's also the build management system, test framework, etc. It's the ecosystem. It not only introduces supply chain attacks. It also introduces other attacks directly from the owners such as vengeful removal of packages, changes in CoC that ban certain libraries, etc. I don't like it. Of all package managers, it makes me feel the worst.
- wredue 3y ago
  The issue is that if your language doesn’t NPM-ize your packages, developer write you off as not modern enough. The simple fact is that this seems to be what most developers want, AND this is not limited to JavaScript developers.
- howinteresting 3y ago
  The ease of use outweighs the security concerns for most reasonable people.
empath-nirvana 3y ago
> Several soundness issues were found in previous versions of the standard library that allow a malicious crate to take advantage of undefined behavior to run arbitrary machine code. It seems likely to me that there are similar unknown issues lurking in today's standard library or compiler. Even without any soundness issues or bugs or security flaws, people can just plain write malicious code. Rust prevents a lot of common _mistakes_, but people can also use it to write completely "safe" worms that are guaranteed not to have use-after-free errors, data races and unexpected panics. I don't think there's any way to get around the social aspects of software security for most developers ("trusting _people_ not code")
- binary132 3y ago
  And yet hardly anyone ever makes this argument against sandboxing the code we download on demand every single day while browsing the internet. I have started to believe we should think of open-source software as not so different, and sometimes even as less trustworthy in certain ways since we typically don’t sandbox it. How many of your tools have telemetry? How many of your drivers do? How many download and execute stuff on the fly?
  - tentacleuno 3y ago
    That's completely different, though. JavaScript is sandboxed (and a lot of effort goes into ensuring that), while build-time macros (and runtime code) runs on the machine in an unrestricted manner. Not sure what your point is.
- fleventynine 3y ago
  > Even without any soundness issues or bugs or security flaws, people can just plain write malicious code. Rust prevents a lot of common _mistakes_, but people can also use it to write completely "safe" worms that are guaranteed not to have use-after-free errors, data races and unexpected panics. The idea here is that if the "evil crate" is prevented by the compiler to call out into any os functionality or use unsafe, the worst it can do is return bogus values, mutate anything it has a &mut reference to, and leak heap memory. And if the toolchain were perfect, that might be achievable. This was the promise that Java Applets made, which wasn't achievable due to the JVM being too bug-prone.
remram 3y ago
Why would macros need sandboxing if the crate build doesn't have any? What is your threat model? Without proc macros, running `cargo build` or `cargo check` can already do anything via `build.rs` scripts. Without that, you still run arbitrary code from crates.io if you do `cargo run` or `cargo test`.
louislang 3y ago
We're actively working on this with our sandbox (https://github.com/phylum-dev/birdcage https://github.com/phylum-dev/birdcage). We've wrapped the likes of pip, yarn, and npm already and are making moves to similarly provide support for cargo. Currently comes as part of the Phylum CLI (https://github.com/phylum-dev/cli https://github.com/phylum-dev/cli), so that doing something like: phylum npm install <somePkg> Will reach out to the Phylum API to ask what we know about it (e.g., does the source have characteristics congruent with malware?), if that passes it'll then install the package from within the confines of the sandbox with limited disk, network and env access (as defined by allowed resources in the TOML file).

bitwize 3y ago

If you're not sandboxing, you're asking to get pwned.

goku12 3y ago

> I would love it if cargo had a mechanism to run all build actions for a crate inside a firecracker vm Why not go in the other direction? A tool that can set up a VM with source code and build tools based on a declarative file? That could work for any language - not just Rust. Sort of like a completely local CI system.

oneshtein 3y ago
Who will verify VM, your local CI, and produced binary?
- goku12 3y ago
  The idea of the microVM is to isolate the build system from the host. Your question is beyond the scope of the original problem.
remram 3y ago
You're describing Vagrant.
- goku12 3y ago
  Ah! You're right. I wonder if vagrant is enough to mitigate these concerns.

zer8k 3y ago

> If you care about security, you have to audit your dependencies very carefully The problem is Cargo is yet another iteration of the npm-ization (maven-ization?) of code. It requires a BDFL or a team of such BDFLs to proactively police the repos in order to prevent trivial supply chain attacks. Your statement misses the point that not only do people NOT do this it's now trivial to avoid it with Cargo. This is not the same security risk that is present if you use git submodules and build with a makefile. The key difference is ease of use. Cargo, like NPM and to some extent Maven, are so easy to use you've accidentally created a massive attack surface. The result will likely be yet another incarnation of JFrog or the like. Code will be audited, built into dylibs, and then pinned via some enterprise supply chain manager. This is a big lift for companies who might otherwise switch to Rust for new projects quicker. Cargo is my main gripe with Rust almost all the time. So many people say "you can just build manually with rustc!" but this is not true. It's not as simple. Again, it would also be one thing if Cargo was just the package manager but it's also the build management system, test framework, etc. It's the ecosystem. It not only introduces supply chain attacks. It also introduces other attacks directly from the owners such as vengeful removal of packages, changes in CoC that ban certain libraries, etc. I don't like it. Of all package managers, it makes me feel the worst.

wredue 3y ago
The issue is that if your language doesn’t NPM-ize your packages, developer write you off as not modern enough. The simple fact is that this seems to be what most developers want, AND this is not limited to JavaScript developers.
howinteresting 3y ago
The ease of use outweighs the security concerns for most reasonable people.

empath-nirvana 3y ago

> Several soundness issues were found in previous versions of the standard library that allow a malicious crate to take advantage of undefined behavior to run arbitrary machine code. It seems likely to me that there are similar unknown issues lurking in today's standard library or compiler. Even without any soundness issues or bugs or security flaws, people can just plain write malicious code. Rust prevents a lot of common _mistakes_, but people can also use it to write completely "safe" worms that are guaranteed not to have use-after-free errors, data races and unexpected panics. I don't think there's any way to get around the social aspects of software security for most developers ("trusting _people_ not code")

binary132 3y ago
And yet hardly anyone ever makes this argument against sandboxing the code we download on demand every single day while browsing the internet. I have started to believe we should think of open-source software as not so different, and sometimes even as less trustworthy in certain ways since we typically don’t sandbox it. How many of your tools have telemetry? How many of your drivers do? How many download and execute stuff on the fly?
- tentacleuno 3y ago
  That's completely different, though. JavaScript is sandboxed (and a lot of effort goes into ensuring that), while build-time macros (and runtime code) runs on the machine in an unrestricted manner. Not sure what your point is.
fleventynine 3y ago
> Even without any soundness issues or bugs or security flaws, people can just plain write malicious code. Rust prevents a lot of common _mistakes_, but people can also use it to write completely "safe" worms that are guaranteed not to have use-after-free errors, data races and unexpected panics. The idea here is that if the "evil crate" is prevented by the compiler to call out into any os functionality or use unsafe, the worst it can do is return bogus values, mutate anything it has a &mut reference to, and leak heap memory. And if the toolchain were perfect, that might be achievable. This was the promise that Java Applets made, which wasn't achievable due to the JVM being too bug-prone.

remram 3y ago

Why would macros need sandboxing if the crate build doesn't have any? What is your threat model? Without proc macros, running `cargo build` or `cargo check` can already do anything via `build.rs` scripts. Without that, you still run arbitrary code from crates.io if you do `cargo run` or `cargo test`.

louislang 3y ago

We're actively working on this with our sandbox (https://github.com/phylum-dev/birdcage https://github.com/phylum-dev/birdcage). We've wrapped the likes of pip, yarn, and npm already and are making moves to similarly provide support for cargo. Currently comes as part of the Phylum CLI (https://github.com/phylum-dev/cli https://github.com/phylum-dev/cli), so that doing something like: phylum npm install <somePkg> Will reach out to the Phylum API to ask what we know about it (e.g., does the source have characteristics congruent with malware?), if that passes it'll then install the package from within the confines of the sandbox with limited disk, network and env access (as defined by allowed resources in the TOML file).