# Build Security
**URL:** https://internals.rust-lang.org/t/build-security/24166
**Category:** cargo
**Created:** [April 10, 2026, 6:14pm UTC](https://internals.rust-lang.org/t/build-security/24166 "2026-04-10T18:14:42Z")
**Posts on this page:** 12
**Page:** 2
### Author:  [@zackw](https://internals.rust-lang.org/u/zackw)
#### Post date: [July 8, 2026, 4:57pm UTC](https://internals.rust-lang.org/t/build-security/24166/21 "2026-07-08T16:57:14Z")
> [@MusicalNinjaDad](#):
>
> I'd also expect security issues in major IDEs & LSPs to found, CVE-d and patched a lot more effectively than in any single crate.
The trouble with this reasoning is that the capabilities "ask editor to read file on disk and provide contents to LSP server" and "ask editor to write file on disk with contents specified by LSP server" are dual-use.\[1\] Their existence is not necessarily a security problem in and of itself, and they might well have been added to the protocol on the assumption that the LSP server is trusted and runs with the ambient authority of the invoking user _anyway_. It _becomes_ a security problem when we introduce a sandbox, and there's something untrusted, inside the sandbox, that either is, or can _masquerade as_, an LSP server, to an editor outside the sandbox.
> Leveraging any of these gaps from a build script either requires control of the crate, LSP and possibly IDE, or a zero-day.
I thought we were assuming the entire crate to be malicious, since that's the whole point of sandboxing the build, to protect the exterior of the sandbox from malicious code in a crate being built.
> The main point I take though is that the vector `repo-contents -> internet` is not well covered by this case. That's certainly a member of the shortlist for "not covered".
Yeah, absolutely. I would worry about that _before_ I worried about LSP servers puppeting editors.
* * *
1. to reiterate, I don't know if the LSP protocol provides LSP servers with these capabilities, but I'm assuming it does for purpose of this discussion
---
### Author:  [@MusicalNinjaDad](https://internals.rust-lang.org/u/MusicalNinjaDad)
#### Post date: [July 8, 2026, 5:01pm UTC](https://internals.rust-lang.org/t/build-security/24166/22 "2026-07-08T17:01:12Z")
> [@zackw](#):
>
> I thought we were assuming the entire crate to be malicious, since that's the whole point of sandboxing the build, to protect the exterior of the sandbox from malicious code in a crate being built.
the emphasis should have been more clearly on the _and_ - just having a malicious crate is no longer enough for this vector
---
### Author:  [@zackw](https://internals.rust-lang.org/u/zackw)
#### Post date: [July 8, 2026, 6:04pm UTC](https://internals.rust-lang.org/t/build-security/24166/23 "2026-07-08T18:04:58Z")
Thanks for the clarification; I indeed missed the importance of the "and". But I don't think you need all three of the things on your list for the exploit I described. I think you need:
- a malicious crate being built inside a sandbox
- the IDE-to-LSP-server _communication channel_ being exposed to code running inside the sandbox
- an IDE that exposes "read/write arbitrary file with user ambient authority" to LSP servers (which is not technically a _vulnerability_ in the IDE or the protocol)
If you consider the LSP server a trusted component, only containerized for ease of installation, then you can probably avoid this exploit by moving it to a _separate_ container (that's no longer considered a sandbox), thus not needing to poke a hole in the sandbox for the LSP socket. However, then the LSP server needs to know how to run build steps inside the sandbox container. I don't know if rust-analyzer is flexible enough for that.
---
### Author:  [@RalfJung](https://internals.rust-lang.org/u/RalfJung)
#### Post date: [July 10, 2026, 4:12pm UTC](https://internals.rust-lang.org/t/build-security/24166/24 "2026-07-10T16:12:26Z")
> [@epage](#):
>
> EDIT: I also very much want us to explore
>
> - reducing the need for build-rs ( [Reduce the need for users to write build scripts · Issue #14948 · rust-lang/cargo · GitHub](https://github.com/rust-lang/cargo/issues/14948) )
> - consolidate build scripts via build script delegation, reducing the audit surface ( [Tracking issue for RFC 2196, "metabuild: semantic build scripts for Cargo" · Issue #14903 · rust-lang/cargo · GitHub](https://github.com/rust-lang/cargo/issues/14903) )
> - explore how far we can go with declarative macros to replace proc-macros
None of these will fully replace build scripts and proc macros. So while they are great initiatives, they do not substantially change the need for sandboxing.
And I do think it is a need. I hate how paranoid I have to be about even checking source code in an IDE or otherwise locally, and I am far from sure that my hand-crafted sandbox setup is totally airtight...
---
### Author:  [@epage](https://internals.rust-lang.org/u/epage)
#### Post date: [July 10, 2026, 4:40pm UTC](https://internals.rust-lang.org/t/build-security/24166/25 "2026-07-10T16:40:42Z")
> [@RalfJung](#):
>
> None of these will fully replace build scripts and proc macros. So while they are great initiatives, they do not substantially change the need for sandboxing.
>
> And I do think it is a need. I hate how paranoid I have to be about even checking source code in an IDE or otherwise locally, and I am far from sure that my hand-crafted sandbox setup is totally airtight...
When most people talk about sandboxing, it comes across as the more general problem of "dangerous things might run on my system". I think it was this thread is the first I heard of the more specific use case of "I want to review the code before running it unprotected".
A potential alternative to sandboxing for proc-macros is build-std where we could statically determine that a proc-macro is alloc-only (yes, something would need to be figured out for FFI).
Note that for either solution, last I heard from project security folks, they do not want to officially consider the compiler to be a security barrier against untrusted code.
There will be proc-macros that won't fit into either solution and there are still some build scripts after efforts of reducing their use. The scope of what is left is up for debate for how much we allow for exposing through sandboxing. At [#t-cargo \> build script and proc macro allow list @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20script.20and.20proc.20macro.20allow.20list/near/595506317), I have started exploring the idea of allow lists for the remaining proc macros as well as build scripts. One idea there for build scripts is package authors information cargo when a build script is optional (e.g. some view `anyhow` build script this way), reducing the amount of build scripts to be allowlisted even further.
---
### Author:  [@RalfJung](https://internals.rust-lang.org/u/RalfJung)
#### Post date: [July 10, 2026, 8:07pm UTC](https://internals.rust-lang.org/t/build-security/24166/26 "2026-07-10T20:07:32Z")
> [@epage](#):
>
> I think it was this thread is the first I heard of the more specific use case of "I want to review the code before running it unprotected".
Happy to register this as a use-case then. 🙂I might not want to run (most of) it at all, but just understand it while debugging a crater regression or a Miri report or something like that -- to then copy-paste the relevant parts and run those.
---
### Author:  [@jrose](https://internals.rust-lang.org/u/jrose)
#### Post date: [July 12, 2026, 12:05am UTC](https://internals.rust-lang.org/t/build-security/24166/27 "2026-07-12T00:05:51Z")
> [@epage](#):
>
> A potential alternative to sandboxing for proc-macros is build-std where we could statically determine that a proc-macro is alloc-only (yes, something would need to be figured out for FFI).
Yeah, I don't think this is merely a library problem, you'd need to ban `extern` and `link` and inline asm at the very least. "This crate does nothing beyond what `alloc` can do" is a full language dialect of enforcement.
---
### Author:  [@fintelia](https://internals.rust-lang.org/u/fintelia)
#### Post date: [July 12, 2026, 6:41pm UTC](https://internals.rust-lang.org/t/build-security/24166/28 "2026-07-12T18:41:03Z")
You'd almost surely need to ban all unsafe code. If OS-level protections aren't enabled, it would just be a matter of casting a function pointer to a writable data pointer and overwritting with the desired machine code.
But even something like "write XOR execute" memory protection doesn't help much. The ability to easily clobber the stack would make it straightforward to use return-oriented programming to hijack control flow. And the attacker could even intentionally add functions with lots of ROP gadgets.
---
### Author:  [@ais523](https://internals.rust-lang.org/u/ais523)
#### Post date: [July 13, 2026, 2:42pm UTC](https://internals.rust-lang.org/t/build-security/24166/29 "2026-07-13T14:42:49Z")
Banning unsafe code is not enough. You'd also need to ban safe code that has undefined behavior (which is nontrivial to do given how many soundness bugs Rust has, some of which are very hard to fix); otherwise, safe code could be used to do the same thing that unsafe code does.
I've thought for a while that `rustc` should have an option to redo the type and lifetime check post-monomorphization, as a method of guarding against soundness bugs. You would need something like that for banning `unsafe` code to have any value. However, I suspect it's hard to implement given the current compiler architecture (and even that would only catch type-checking-related unsoundnesses, not other sorts of miscompile).
---
### Author:  [@miro](https://internals.rust-lang.org/u/miro)
#### Post date: [August 25, 2026, 6:46pm UTC](https://internals.rust-lang.org/t/build-security/24166/30 "2026-08-25T18:46:17Z")
stupid question: what's preventing an attack from just calling their malware from commonly used functions in the infected library, which will be executed when you test it locally, to bypass the sandbox?
---
### Author:  [@ProgramCrafter](https://internals.rust-lang.org/u/ProgramCrafter)
#### Post date: [August 25, 2026, 8:50pm UTC](https://internals.rust-lang.org/t/build-security/24166/31 "2026-08-25T20:50:28Z")
Not running the tests. When cross-compiling, as an example.
---
### Author:  [@miro](https://internals.rust-lang.org/u/miro)
#### Post date: [August 27, 2026, 12:32pm UTC](https://internals.rust-lang.org/t/build-security/24166/32 "2026-08-27T12:32:44Z")
i meant "when you test locally" as in when you are developing a application and run the application you're developing on your computer to see if it works, not running the test suite (although now that i think about it tests have the same issue for libraries, and sandboxed tests would not just help with security but also with reproducibility).
when cross compiling I'd still try to find some way to actually run what I compiled to see if it works, and while it's possible that the method I use accidentally sandboxes the application the chances are very high that it has the same permissions as a normal process (e.g. when cross compiling from linux to windows i'd likely just run the exe in wine).
[Previous page](https://internals.rust-lang.org/t/build-security/24166.md?page=1)