NOEXEC and RESTRICT in sudoers

Question

I understand the script below has a serious problem, and NOEXEC and RESTRICT are not enough as a solution to this.

user ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

However, I still have some confusion with these two options.

RESTRICT

Due to the large number of programs that offer shell escapes, restricting users to the set of programs that do not is often unworkable.

Why is this a problem? I should not allow normal users to execute arbitrary commands, so restricting normal users to programs which do not allow shell escapes seems the same as sudoedit. How is this different from sudoedit?

NOEXEC

The noexec feature is known to work on SunOS, Solaris, *BSD, Linux, IRIX, Tru64 UNIX, MacOS X, HP-UX 11.x and AIX 5.3 and above.

If you are unsure whether or not your system is capable of supporting noexec you can always just try it out and check whether shell escapes work when noexec is enabled.

Is there a good way to check if NOEXEC works well or not? Is trying commands out the safest?

man page: http://www.sudo.ws/sudoers.man.html

Answer 1

RESTRICT

The way I interpret "restricting users to the set of programs that do not [allow shell escapes] is often unworkable", it means that it is so common for programs that, on the surface, seem to perform a single, safe task, but actually allow one to run any other program, that one should assume, in the general case, that giving a user access to a single command will in fact allow them to run any command they want.

The typical example is perhaps text editors: apart from allowing the user to open any file from within the editor, not just the file that was given on the command line, popular editors allow one to start a full shell.

The sudoedit mechanism provides an editor that is constrained to editing only a specific file (by giving the user a copy of the file to be edited, letting them edit it as themselves, on only after that updating the privileged file). If one were to use RESTRICT to let a user run, say, emacs, on a specific files then that user, from within the emacs editor running as a privileged user, could in fact edit any file accessible to that user, and start a shell as that user.

NOEXEC

When a program is started this way, its normal dynamic libraries are replaced to forbid spawning a new shell. This should make it so that attempting to start a shell command from within, say, less should fail, provided that less is a dynamic executable. In the case where one wants to allow editing a specific file, it is probably safer and nicer to the user to use sudoedit (because then they have access to their own editor's custom settings).

As to checking whether NOEXEC will work on your system, I assume it will on any operating system listed on the documentation, provided that the target program is indeed dynamically linked. But it's best to check by hand, as the documentation suggests.