Let's say I have an app that is written in Rust (e.g. by myself) and I want to install it system-wide (e.g. on Ubuntu). I could do something like this:
sudo cargo install --path . --root /usr
But I also heard that running sudo cargo is unsafe, because some dependency might do something malicious during the build process.
So what do people usually do? Run cargo without sudo but put the binary to some temporary location and then move it yourself to /usr/bin? Is this at all different from just running cargo build --release? Would it be safer to use cargo-deb?
I use cargo-deb to build an installable package as a non-privileged user, then install that package as root (as with any other local package: apt-get install ./target/…/whatever-0.1.0_0.deb).
In a past life, I have also built binaries as a non-privileged user and copied them into /opt or /usr/local. Works fine.
You can run cargo install as root, and I've done it (eg. in Docker container builds), but keep in mind that it runs the whole build process, including any build scripts in your dependencies, as root as well. You need to make a decision about whether you want to allow that.
That's meaningfully an issue either if the final binary is setuid root (in which case it can act as root at runtime), or if the final binary will be run by root (ditto), or if the threat model you're looking at includes access to the user's own data (which, IMO, is often an underappreciated risk area).
Rust builds, with or without sudo, run arbitrary code. You're going to run the executable too, so you have to trust the project you're installing (it has power to install account-level malware and then elevate that through other weakness or wait until you run sudo for something else).
But the real problem is that Cargo isn't the right tool to install things system wide, especially on Ubuntu/Debian that already has a proper package manager.
cargo-deb even has an --install flag for this purpose.
To be honest there is nothing specific to rust about this. If one builds a C++ app, its dependencies could be malicious as well, as could the build system it uses.
So if you really want to tackle the problem, you'd have to tackle it for every program, in every programming language. That's a bit of an auditing nightmare though to be honest, because it's been known for a long time now that even the compiler can be patched to contain malicious code without it showing up in the source code.
So ultimately (and not in a philosophical way) the question is, how a serious are you about this?