Why is it risky to give sudo vim access to ordinary users?
Solution 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 RESRICT
and 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 theNOEXEC
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).
Solution 2
The simple answer:
The following is a Vim command:
:shell
They now have a root shell.
Solution 3
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
Solution 4
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.
Solution 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 /
.
Related videos on Youtube
mi0pu
Updated on September 18, 2022Comments
-
mi0pu over 1 year
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?
-
John1024 over 9 yearsFor one, your command will give the user read and write access to all files on the computer. Once in
vim
, the user is free to open and write to any file he pleases. -
iyrin over 9 yearsAs an aside, you can create a new group to add any user needing access to
/etc/httpd/confs/httpd.conf
. Then usechgrp [OPTION] GROUPNAME FILE
to change the group ownership of/etc/httpd/confs/httpd.conf
. Something likegroupadd vimportant
to create the new group andchgrp -v vimportant /etc/httpd/confs/httpd.conf
to change group ownership. yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html -
Michał Politowski over 9 yearsNote that, because of all the problems mentioned in the answers, sudo includes a way to allow users to edit files with an editor running with their own privileges. Look for "Secure editing" in the
sudoers
man page. -
fedorqui over 9 years(Not sure if what I say is right) Since you are giving
sudo
access to vim, the user will be able to use vim as root. In vim you can run UNIX commands (How to run Unix commands from within Vim?) so a user would be able to do thing likeuseradd <myuser>
,rm -rf /
or many other things. -
jason dancks over 9 yearsdepending on how the system is set up they could also do ':! /bin/sh' and get a root shell. a classic.
-
Nate Eldredge over 9 yearsThis is sort of the wrong question to be asking. When considering granting elevated privileges of any kind, you don't want to be thinking "I will do this, unless I think of some reason why it is dangerous." You want to think "I won't do this, unless I can prove to myself that it is safe."
-
Admin over 9 years@jasondancks I've had sudo on too many systems where that was a possibility.
-
reirab over 9 years@NateEldredge You should also be thinking "I won't do this unless I really need to." Principle of least privilege is a good thing to follow. Giving a user sudo access to edit a single file is like trying to swat a fly with a sledgehammer; it might get the job done, but it could also have some serious unintended consequences.
-
Wildcard over 7 years
-
-
mi0pu over 9 yearsWhat do you mean by "This configuration allows all users to edit that file"? Does "user" have a special meaning?
-
michas over 9 yearsOops, did not pay attention. fixed the answer.
-
jasonwryan over 9 yearsIs this supposed to be an answer or a cut and paste error?
-
mi0pu over 9 yearsI did not know that
sudo tar
andsudo unzip
also cause problems. Thank you. -
Hauke Laging over 9 yearsMost of that isn't related to the question.
-
user over 9 yearsNice answer. It would be even better if it also mentioned escaping from within vim into a shell. Once you're in a shell, it's free-for-all, and still all that would show up in the logs is that the user is editing your Apache configuration file.
-
Wayne Werner over 9 yearsAdditionally? If you're using vim you could do something horrible, like
:!rm -rf /
, whoops! -
Qix - MONICA WAS MISTREATED over 9 years
echo "user ALL=(ALL) NOPASSWD: ALL" > ~/sudoers; tar cv ~/sudoers | sudo tar xv -C /etc
And boom. Root access to tar is a vulnerability. -
Joshua over 9 yearsYou know you could have arranged for SHELL=/bin/true when spawning vim, right? Still a bad idea for overwriting such files as /etc/passwd.
-
vurp0 over 9 yearsUnfortunately, this is also 100% insecure. If the user manages to edit /etc/sudoers to make himself omnipotent on the system, then he can run any command as root.
-
Wildcard over 7 years@MichaelKjörling, I was expecting that answer also, and not finding it, I wrote it. :)
-
Wernfried Domscheit over 4 yearsShould be noted to grant
user ALL=(ALL) sudoedit ...
rather thanuser ALL=(ALL) /usr/bin/sudoedit ...
. If your grant sudo to/usr/bin/sudoedit
then it is basically the same like grantingsudo vi
which have security flaws.