Question: shouldn't `$PATH` be reset by default?

[bryango]

It seems that the default sudoers config keeps the $PATH environment variable:

https://github.com/sudo-project/sudo/blob/3899f2ef90982735f1ea22a8da190ac8e53d8d1e/plugins/sudoers/env.c#L213-L229

I understand that this may have been the default for some decades already, but it still makes me a bit uneasy... Many popular distros enforce a secure_path in their sudoers; e.g.

• debian: https://salsa.debian.org/sudo-team/sudo/-/blob/master/debian/etc/sudoers?ref_type=heads#L11
• fedora: https://src.fedoraproject.org/rpms/sudo/blob/rawhide/f/sudoers#_88

However, other distros such as Arch choose to keep the default config, which seems to be a security risk. I only noticed this difference recently, as I converted from ubuntu to Arch. I have hence set Defaults env_keep -= "PATH" in my config, but I wonder if this should be the default; in other words, should we strike PATH off the initial_keepenv_table, or will this cause too much disruption with little security benefits?

P.S. Thank you for maintaining this critical program for decades!

[millert]

I'm not sure that there is much security benefit to changing this. I think secure_path can be useful when it adds things like /sbin and /usr/sbin that user's don't necessarily have in their default PATH. But since sudo only allows commands to be run that match sudoers I don't think it is really needed.

The only real security risk I see is one where a user's startup files have been compromised and thus they can be tricked into running a malicious command via sudo if the user has ALL permissions. But secure_path doesn't really defend against that since the malicious party could simply substitute a trojaned sudo binary to steal the user's password.

[bryango]

But secure_path doesn't really defend against that since the malicious party could simply substitute a trojaned sudo binary to steal the user's password.

Ah, indeed, that's totally true! Thank you for explaining this! Closing...

the malicious party could simply substitute a trojaned sudo binary to steal the user's password.

By the way, is there anything that I can do to defend against this? The only thing that comes to my mind is that

su()   { /bin/su   "$@"; }
sudo() { /bin/sudo "$@"; }
alias su=/bin/su
alias sudo=/bin/sudo

But this only prevents shadowing in the current shell session.

[j5k]

But since sudo only allows commands to be run that match sudoers I don't think it is really needed.

If the allowed scripts use relative path to commands (like cp, mv, etc.) you are vulnerable too! :thinking: