Sudo 1.9.16 is now out, containing mostly bug fixes. However, there are also some new features, like the json_compact option I wrote about a while ago. The other major change is, secure_path is now enabled by default in the sudoers file, and there is a new option to fine-tune its content.

As usual, operating systems usually lag behind with sudo versions. If your OS does not have yet 1.9.16 or later, there is a good chance that you can find a ready to use installer on the sudo website at https://www.sudo.ws/getting/download/#binary.

Most environment variables from the user are preserved, so they can have a similar experience under sudo as in their regular environment. One of those environment variables is PATH, which determines which directories are searched when a user types an application name without a full path.

The secure_path sudoers option overrides the user’s PATH environment variable with a value that is considered to be “safe”. Typically, this means system binary directories such as /usr/local/bin, /usr/local/sbin, /usr/bin, and /usr/sbin. sudo uses this value of PATH used when searching for a command to run that doesn’t have a full path. It is also inherited by the applications run by sudo.

While sudo itself matches fully-qualified path names in the sudoers file, applications invoked via sudo may run additional programs themselves, without using a full path. For example, imagine that an application run by sudo removes a temporary file by running rm /tmp/prog.tmp. Without secure_path, it is possible for a user to create a harmful application with the name rm in a directory they control, and put that directory first in their PATH. Then, when the command run by sudo runs rm, it will run the harmful application instead.

Setting secure_path in the sudoers file prevents this attack. Applications run by sudo are executed only from the path considered secure by the administrator, and this value of PATH is also used by the running application.

The value of secure_path is set by the configure script when building sudo. It has a reasonable default value. However, you can override it using the --with-secure-path-value configure option. You can disable using secure_path by deleting or commenting it out from the sudoers file. In this case, sudo falls back to the old behavior.

You should check your sudoers file and configure secure_path if it is not yet there. On the positive side, I must also mention that there is a good chance that secure_path is already configured for you by your Linux distribution. At least that was the case on the Linux distributions I use regularly (openSUSE, Fedora, RHEL).

If you would like to be notified about new posts and sudo news, sign up for the sudo blog announcement mailing list.