I recently came across a default SLES installation which has the following $PATH:
(truncated for clarity)
/sbin:/usr/sbin/:${HOME}/bin:/bin:/usr/sbin/:/usr/local/bin ..........
This at first glance appears as a security problem , as a malevolant user can add $HOME/bin/ls and a user can execute a different ls or other arbitrary command that does something totally different.
However, changing the path around to :
/sbin:/usr/sbin/:/bin:/usr/sbin/:${HOME}/bin:/usr/local/bin ..........
Does not really help the situation. The security problem that is exploited by the faulty path, is not fixed.
The security experts at SuSE explain:
If a user has write access to directories belonging to another user, then it does not matter what the PATH settings are, the target account is very likely to be compromisable for any local attacker. This is not what a unix-like system protects against. Especially the root account is (must
be) considered trusted, as it has the privileges to add/remove users or set new passwords – not to mention accessing all files in the system.
In this case, the PATH setting is actually a feature: The user can substitute programs contained in /usr/bin and other, non-system bin directories by placing a script/wrapper/other version of the program within his own bin dir.
The execution of a program and the control of what executes (such as with a command executed by the shell) happen at the same security level within a Linux system. Therefore, the PATH setting cannot be considered a security risk.
Entirely different is the following problem: If the PATH is set to /tmp or another, world writeable directory, then its place in the sequence of directories does matter, of course. Even if these directories, or “.” for that matter, are moved to the end of the PATH variable, a local attacker can still place a script with the name of an anticipated typo into the directory, thereby tricking the user or root into running it. This is why we have the option to include “.” into the PATH, but it is disabled by default.