5 tools you should not be able to run as root

If you plan to restrict utilizing the root user under Linux, it is most likely that you will create sudo rules to allow certain users to execute administrative utilities. There are plenty of tools you really should not be able to run as privileged users - some examples:

screen, tmux

The famous terminal multiplexers GNU Screen and tmux automatically create a login shell when starting a new session. Therefore, you really should not start them with root privileges:

1$ sudo screen
2# whoami

A better approach would be to start the multiplexer with conventional permissions and start administrative sessions on a per tab basis.

vi / vim

The vi and Vi IMproved editors offer additional functions - e.g. starting processes (:!) or redirecting process output into the current document (:r!). If is possible to start the editor with root privileges, it is also possible to escape and start a root shell:

1$ sudo vim myfile
4# whoami

The most vi/vim installations also include the rvi and rvim commands which lack this feature (restricted vi/vim). If you really need to start editors as root, it is advisable to use one of the alternatives just mentioned.

more, less, view

For viewing log files and others documents, the utilities more or less and sometimes also view are very common. It is often forgotten that these utilities can switch to edit mode using vi or vim by pressing the v key. Again, using this it is no big deal to escape and start a root shell:

1$ sudo less /var/log/messages
4# whoami

If you are using a source-based Linux distribution such as Gentoo or CRUX and need to compile less by yourself, you can disable this behavior (--with-secure). Alternatively you can set the environment variable LESSSECURE to 1 to disable this behavior. But as you know, it is also quite easy to change shell variables again. When using more, keep in mind that this behavior can not be disabled at all.

Another option would be to use rview instead of view.


Red Hat Software Collections (SCL) mainly manages alternative program versions - but it can also be used to start a privileged terminal session:

1$ sudo scl enable httpd24 bash
2# whoami


find is not just capable of finding files - using the -exec parameter it can also execute files. The following example demonstrates starting a root shell:

1$ sudo find /bin -name bash -exec {} ;
2# whoami

But - in some scenarios it might be essential to run find as root. How should we deal with this?

Fixing using noexec

All vulnerabilities behave in the same way from an operating system perspective - child processes are created using the fork() and execve() system calls. E.g. for the find trick:

1$ pstree
4   ├─find
5      ├─bash

Inside a bash session, find was executed and starting a privileged bash session using sudo.

This behavior can be strictly forbidden using the NOEXEC: sudo parameter. As a result, only the former program can be executed with root privileges, additional child processes cannot be started - an example:

1# vi /etc/sudoers.d/admins-editors
2%admins    (ALL) = NOEXEC: /usr/bin/vi

Let's try to run a root shell using vi/vim:

1$ sudo vi /etc/myapp.conf
5Cannot execute shell /bin/bash

When using FreeIPA or Red Hat Identity Management (IdM) the parameter needs to be entered in lower-case (noexec instead of NOEXEC:) - it is specified on a per rule basis. An example: