09 Oct 2024

Stop Running Your Text Editor as Root

What do you do when you need to edit a file owned by root, for example /etc/hosts or /etc/ssh/sshd_config? Most people I know simply call something like sudo vim /etc/ssh/sshd_config.

What if I tell you that there’s a better way?

Indeed, why would we need to grant a text editor (and its plugins) 0000003fffffffff capability mask? The principle of the least possible privileges says that we should have only those privileges that are absolutely necessary for our task. In order to edit a file text editor certainly don’t need e.g. CAP_NET_BIND_SERVICE that allows to listen on the privileged ports or CAP_SYS_PTRACE that lets to access the memory of arbitrary processes. To think about it, even if we drop all capabilities, but still have effective user ID as root, it’s already an overkill, because it allows to edit any file owned by root, not only the one that we requested.

Fortunatley there’s a standard solution to this problem: sudo -e, aka sudoedit (the latter is just a symlink to sudo that makes it behave as if it was invoked with -e option).

The man page will tell about it better than me, so I just leave it here:

-e, --edit  Edit one or more files instead of running a command.  In lieu
                 of a path name, the string "sudoedit" is used when consulting
                 the security policy.  If the user is authorized by the pol‐
                 icy, the following steps are taken:

                 1.   Temporary copies are made of the files to be edited with
                      the owner set to the invoking user.

                 2.   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.

                 3.   If they have been modified, the temporary files are
                      copied back to their original location and the temporary
                      versions are removed.

— man sudo

So, next time instead of sudo nano <file-name> be hip and call sudo -e <file-name> ¹. The editor will run under unprivileged user and then sudo will copy the result to the protected file.

If you do it from other person’s workstation, you can specify your preferred editor through the environment variable, e.g. EDITOR=vim sudoedit <file-name>.

Using sudoedit should be a basic cybersecurity hygiene habit, on the level of not running your desktop environmen as root. But for some reason it’s almost unknown and I still see sudo vim / sudo nano everywhere in books, manuals, blog posts.

— User manual of a certain Linux distribution

The more you notice it, the more annoying it becomes. The tipping point that made me write this post was an alias from one of the collections of “awesome dot files” (or something like this): alias hosts='sudo $EDITOR /etc/hosts'

I hope I managed to transfer at least a tiny piece of my madness to you, my dear reader, and the next time you stumble on sudo vim you bother to take time and make a change request to fix documentation and spread the knowlege.

Upd

After I published this note I got a useful comment from @bemyak.

In case of vim / nvim / helix there’s a nice trick: you can open a file as an unprivileged user and then save it like this:

:w !sudo tee %

This works for the most cases, except when a file is inaccessible for a regular user.