rustup configure an insecure PATH by default.

[sha0coder]

Problem

Configuring the cargo path in the first section of the $PATH creates an extra insecurity on the system, as the comment says it's overriding the system binaries. It would be more secure to put the "$HOME/.cargo/bin" at last section of the $PATH.

.cargo$ cat env
#!/bin/sh
# rustup shell setup
# affix colons on either side of $PATH to simplify matching
case ":${PATH}:" in
    *:"$HOME/.cargo/bin":*)
        ;;
    *)
        # Prepending path in case a system-installed rustc needs to be overridden
        export PATH="$HOME/.cargo/bin:$PATH"
        ;;
esac

This gives to a local attacker the possibility of overriding sudo or other binaries to get user password or root access. For sure having access to the account there are other attack vectors, but this open an extra attack vector.

Steps

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Possible Solution(s)

export PATH="$PATH:$HOME/.cargo/bin"

Notes

No response

Rustup version

rustup 1.24.3 (ce5817a94 2021-05-31)                                                                      
info: This is the version for the rustup toolchain manager, not the rustc compiler.                       
info: The currently active `rustc` version is `rustc 1.56.1 (59eed8a2a 2021-11-01)`

Installed toolchains

Default host: x86_64-unknown-linux-gnu                                                                    
rustup home:  /home/sha0/.rustup                                                                          
                                                                                                          
stable-x86_64-unknown-linux-gnu (default)                                                                 
rustc 1.56.1 (59eed8a2a 2021-11-01)

[rbtcollins]

It is true that the current setup permits shadowing distro included binaries, particularly as a side effect of 'cargo install ...'.

However for rustup this is a feature, because rustup should still work even if the distro has included cargo, rustc etc in their system packages.

Thus I don't think there is room to do what you suggest while still meeting our primary use case.

An alternative way to mitigate shadowing would be for there to be two path entries, one for rustups proxies, and one for cargo installed programs, and that second one could be placed at the rear of the path.

We could do that but would need a volunteer to work on it.