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

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

Lines 213 to 229 in 3899f2e

    
           /* 
        
            * Default table of variables to preserve in the environment. 
        
            */ 
        
           static const char *initial_keepenv_table[] = { 
        
               "COLORS", 
        
               "DISPLAY", 
        
               "HOSTNAME", 
        
               "KRB5CCNAME", 
        
               "LS_COLORS", 
        
               "PATH", 
        
               "PS1", 
        
               "PS2", 
        
               "XAUTHORITY", 
        
               "XAUTHORIZATION", 
        
               "XDG_CURRENT_DESKTOP", 
        
               NULL 
        
           };

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.

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!

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.

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.

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! 🤔

	/*
	* Default table of variables to preserve in the environment.
	*/
	static const char *initial_keepenv_table[] = {
	"COLORS",
	"DISPLAY",
	"HOSTNAME",
	"KRB5CCNAME",
	"LS_COLORS",
	"PATH",
	"PS1",
	"PS2",
	"XAUTHORITY",
	"XAUTHORIZATION",
	"XDG_CURRENT_DESKTOP",
	NULL
	};