Why is it risky to give sudo vim access to ordinary users?

Question

I'd like to create a new user and give him sudo access. To be specific, I want him to use sudo vim and edit httpd.conf. I wrote this in sudoers:

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

I, however, heard that this could be risky. Why is this problematic? How serious is the problem?

Answer 1

Although you restrict the commandline arguments there is nothing that prevents the user from using vim to open, edit and overwrite any random file once it is running as root.

The user can run sudo vim /etc/httpd/conf/httpd.conf and then

• clear all that text from the edit buffer
• then for convenience source an existing file (although that is not even required): for instance the sudo configuration
  :r /etc/sudoers NOTE: Unless restricted by SELinux the user can read any file this way!
• grant himself more sudo privileges user ALL=(ALL) NOPASSWD: ALL
• overwrite the old configuration :w /etc/sudoers

I can imagine dozens of similar ways your user can now access, modify or destroy your system.

You won't even have an audit trail which files were changed in this fashion as you will only see him editing your Apache config in the sudo log messages. This is a security risk in granting sudo privileges to any editor.

This is more or less the same reason why granting sudo root level rights to commands such as tar and unzip is often insecure, nothing prevents you from including replacements for system binaries or system configuration files in the archive.

---

A second risk, as many other commentators have pointed out, is that vim allows for shell escapes, where you can start a sub-shell from within vim that allows you execute any arbitrary command. From within your sudo vim session those will run as root, for instance the shell escape:

• :!/bin/bash will give you an interactive root shell
• :!/bin/rm -rf / will make for good stories in the pub.

---

What to do instead?

You can still use sudo to allow users to edit files they don't own in a secure way.

In your sudoers configuration you can set a special reserved command sudoedit followed by the full (wildcard) pathname to the file(s) a user may edit:

user ALL=(ALL) sudoedit /etc/httpd/conf/httpd.conf /etc/httpd/conf.d/*.conf

The user may then use the -e switch in their sudo command line or use the sudoedit command:

sudo -e /etc/httpd/conf/httpd.conf
sudoedit /etc/httpd/conf/httpd.conf

As explained in the man page:

The -e (edit) option indicates that, instead of running a command, the user wishes to edit one or more files. In lieu of a command, the string "sudoedit" is used when consulting the security policy.
If the user is authorized by the policy, the following steps are taken:

• Temporary copies are made of the files to be edited with the owner set to the invoking user.
• The editor specified by the policy is run to edit the temporary files. The sudoers policy uses the SUDO_EDITOR, VISUAL and EDITOR environment variables (in that order). If none of SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed in the editor sudoers(5) option is used.
• If they have been modified, the temporary files are copied back to their original location and the temporary versions are removed.
  If the specified file does not exist, it will be created.
  Note that unlike most commands run by sudo, the editor is run with the invoking user's environment unmodified. If, for some reason, sudo is unable to update a file with its edited version, the user will receive a warning and the edited copy will remain in a temporary file.

---

The sudoers manual also has a whole section how it can offer limited protection against shell escapes with the RESRICTand NOEXEC options.

restrict Avoid giving users access to commands that allow the user to run arbitrary commands. Many editors have a restricted mode where shell escapes are disabled, though sudoedit is a better solution to running editors via sudo. Due to the large number of programs that offer shell escapes, restricting users to the set of programs that do not is often unworkable.

and

noexec
Many systems that support shared libraries have the ability to override default library functions by pointing an environment variable (usually LD_PRELOAD) to an alternate shared library. On such systems, sudo's noexec functionality can be used to prevent a program run by sudo from executing any other programs. Note, ... ...
To enable noexec for a command, use the NOEXEC tag as documented in the User Specification section above. Here is that example again:
aaron shanty = NOEXEC: /usr/bin/more, /usr/bin/vi
This allows user aaron to run /usr/bin/more and /usr/bin/vi with noexec enabled. This will prevent those two commands from executing other commands (such as a shell).

Answer 2

The simple answer:

The following is a Vim command:

:shell

They now have a root shell.

Answer 3

This configuration allows that user to edit that file. In order to do so he starts up a vim editor with root rights.

Once the vim command is started, the user can do whatever he likes with that editor. - He can open a different file or even start a shell out of vim.

Therefore the user is now able to view and edit arbitrary files and run arbitrary commands on your system.

Answer 4

Security locks

Some programs, like for example less, vi, vim and more, allow other programs to run from a shell command-what is known as Shell Escape or escape to the command interpreter. In these cases you can use NOEXEC to prevent some programs allow the execution of other programs privileges. Example:

fulano ALL = (ALL) ALL NOEXEC:  /bin/vi, /usr/bin/less, /usr/bin/vim, /bin/more

This would allow the user to edit or so and privileged view any file on the system running vim and more , but disables the possibility to run other programs with privileges from the escape command interpreter vim.

Importantly sudo includes several security locks (default) that can prevent hazardous tasks, such as redirecting the standard output of the execution of a program (STDOUT) to files outside the user's home directory.

If defined in the file /etc/sudoers that a user can run with privileges /usr/bin/vim, i.e. something like the following:

fulano ALL = (ALL) /bin/echo, NOEXEC: /bin/vi, /usr/bin/vim, /bin/more, /usr/bin/less

sudo allows the defined regular user can run /usr/bin/vim in the following ways:

sudo /usr/bin/vim
sudo vim

But be prevented from running vim as follows:

cd /usr/bin
sudo ./vim

Answer 5

One possible incremental security improvement would be to replace:

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

with

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

and then have the user run sudo rvim /etc/httpd/confs/httpd.conf instead.

Vim supports a restricted mode triggered with the -Z command line option or by starting the program as rvim. When restricted mode is enabled "all commands that make use of an external shell are disabled". This approach would not prevent the user from using a :split file ex command to open other files, but at least should prevent deliberately malicious shell commands like :!rm -rf /.

Answer 6

It should be noted that even a sudoedit {.../whatever.conf} can be a security risk.

Create a shell script /tmp/make_me_root.sh

!#/bin/sh

if [[ ! `grep -c 'domscheit ALL=(ALL) NOPASSWD: ALL' /etc/sudoers` ]] ; then
    echo 'domscheit ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers
fi

and call this script in your config file. I know several examples where this approach is working:

samba -> log nt token command

log nt token command = /tmp/make_me_root.sh

syslog-ng -> program: Sending messages to external applications

log { 
    source{ system() } ; 
    destination { program("/tmp/make_me_root.sh") };
}; 

Apache -> CustomLog

CustomLog "|/tmp/make_me_root.sh"

I assume one can extend this list endless.

All you have to do is to restart the service. Of course, once you are root you will revert such config lines in order to blur your traces.

Answer 7

I agree with HBruijn's answer that running vim as root opens the system very wide indeed, and sudoedit would be a safer solution.

But even then, your system would likely still be rather open. At least assuming that some apache process with root privileges will be launched based on that config. There are a million ways to configure apache in such a way that it will execute external programs. As one example, consider the pipe argument to the CustomLog directive. The manual explicitely states:

Security:

If a program is used, then it will be run as the user who started httpd. This will be root if the server was started by root; be sure that the program is secure.

Obviously, if your users can write the config, they can change that program to anything they like, e.g. something which runs a shell script to grant them further permissions.

For this reason, I've recently hacked together a way to use capabilities in such a way that apache can gain the special capability to bind to a privileged port even though it's otherwise executing as a normal user. That way, users can edit the config and even launch the server, and are still mostly safe. The only problem is that they can bind any process on any IP. A certain degree of trust remains, since they might conceivably find a way to crash the system sshd, and then launch their own version in an attempt to obtain the root password.

Answer 8

Of course, it's not safer at all. As said before sudoedit it's the most easy and suitable way to do it.

What I want to add is that vim allow launch a shell, so, not only can edit any system file, it's also allow to launch a shell and do wherever he wants.

Just try to launch a vim and type :sh