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
3root

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
2ESC
3:!bash
4# whoami
5root

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
2ESC
3:!bash
4# whoami
5root

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.

scl

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
3root

find

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
3root

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
2...
3└─bash
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
2ESC
3:!bash
4
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: