Sandbox build.rs and proc macros

21

That might be a good idea, but we must take care about it.

For example,

bwrap --unshare-all --share-net --die-with-parent \
  --ro-bind / / --tmpfs /sys --tmpfs /tmp --tmpfs /run \
  --proc /proc --dev /dev \
  --bind . `pwd` /bin/sh $COMMANDS

This might not work with all build commands, but it could be really dangerous since you could execute something like cat ~/.cargo/credentials in your build commands and obtain your token in crates.io. (or even worse, your ssh keys is affected in a similar way.)

We should really take care if we run a sandbox.

IMHO, run build as nobody is safer, we may fail, but privates never leaks.

2 Likes
22

I don't know about IDEA, but unfortunately rust-analyzer does not really supports untrusted workspaces in VSCode because cargo can run any code and we need to invoke it to obtain the crate graph :frowning:

2 Likes
23

I consider malware grabbing ~/.cargo/credentials a big risk. There is an RFC that proposes to obfuscate the process a little bit, although even the proposed solution is still insecure, because anyone can ask the credential helper for the credentials:

1 Like
24

Credential helpers can potentially talk to hardware tokens (I have been meaning to investigate doing something with the yubikey crate I wrote in this regard), which can at least make them less of a credential oracle by requiring a manual step such as entering a PIN and/or pushing a physical button on the token.

That won't prevent malware from talking to the credential helper, but it will require user participation in order to obtain a credential, which is better than nothing.

1 Like
25

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.