I love sudo. Yet at the same time I hate the Ubuntu-trend of disabling the root account and give the first user full root privileges through sudo. Hate it with a passion. So in this guide I will explain what sudo is, what it isn’t and how you should use it.
Sudo – superuserdo – is an application which temporarily elevates the privileges of a regular user account to root privileges. This allows a user to run applications or commands with root privileges, even though the account on which the application is running is not a root account. Sudo can be configured to only allow certain predetermined applications & commands be ran with root privileges, or to allow anything and everything which has “sudo” in front of it to run with root privileges.
This is most useful in two cases:
- Untrusted user: If you need to let somebody perform certain administrative tasks on a box but you don’t want to give him / her access to your root account. You give him a regular account and add a line to your /etc/sudoers file allowing him to run all the apps he needs to run with root privileges. He can do the job, but he can’t do anything else to compromise the security of the system.
- Unsecure application: Very few applications should ever be ran as root. If for some reason an application requires root privileges (and you’re sure the application can be trusted and there is no way to do what needs to be done without root privileges) you can allow that application to run with root privileges, and only that application. That way the damage which can be done trough an exploit of the application is minimized; again if and only if the application is not a hacking tool itself.
Now, again, because a lot of people fail to understand this: any application ran with sudo runs with full root privileges, even though it runs from a regular account. If you do not trust an application, do not run it with root privileges, be it from the root account or trough sudo. The application can do pretty much anything it wants to do once you’ve allowed it to run trough sudo, including handing over the controls of your machine to a hacker.
So why bother using sudo at all, if you can’t run anything you don’t trust trough sudo you ask? Because trusted applications are at risk of exploits too. Trough those exploits it is possible for a hacker to inject little pieces of code into your machine. Now if the exploited application is running in a regular user account which cannot run anything but a couple specific applications as root, it’s a lot harder for the hacker to let his malware run with root privileges. He would have to make it look like the malware he injected is part of the binary executable of one of the trusted applications, because only those can be called trough sudo. And because the binary executables can only be modified with root privileges, that’s not an easy task. I’m pretty sure it’s not impossible either, but security is all about staying one step ahead of the bad guys so it does improve security tremendously.
If you’ve paid attention, you now realize the whole sudo-instead-of-root mess canonical pushes the majority of linux users in is actually a security flaw instead of a security enhancement. In Ubuntu the first user account, and any following accounts which get appointed administrator privileges, can run anything trough sudo. Anything at all. That means it just got a whole lot easier for our hacker to get his malware to run with root privileges. All he has to do is log your sudo password and run his code trough sudo. From that moment on it is running with full root privileges.
Configuring sudo is done by editing the /etc/sudoers file trough visudo as root. Visudo is a little application which makes sure no two people are editing the /etc/sudoers file at the same time and which checks the file for basic syntax errors before saving it.
By default visudo uses vi as editor. If you don’t like using vi, run this command to run visudo with nano (or any other editor you prefer) once:
# EDITOR=nano visudo
Here is a very simple example of an /etc/sudoers file from my download server:
# sudoers file. # # This file MUST be edited with the 'visudo' command as root. # Failure to use 'visudo' may result in syntax or file permission errors # that prevent sudo from running. # # See the sudoers man page for the details on how to write a sudoers file. # # Host alias specification # User alias specification # Cmnd alias specification # Defaults specification # Set default editor to nano: Defaults editor=/usr/bin/nano, !env_editor # Runas alias specification # User privilege specification root ALL=(ALL) ALL amie ALL= /usr/bin/pacman # Uncomment to allow people in group wheel to run all commands # %wheel ALL=(ALL) ALL # Same thing without a password # %wheel ALL=(ALL) NOPASSWD: ALL # Samples # %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom # %users localhost=/sbin/shutdown -h now
As you can see in the example above, I’ve changed the default visudo editor to nano and I’ve allowed myself to run pacman (the package manager of Arch Linux) with elevated privileges. This is because I like to use yaourt as a package manager because it can automatically add and update packages from the arch user repositories. However, I do not want to run yaourt with root privileges because it’s not a part of the closest reviewed and most secure “core” applications. Luckily, the people who coded yaourt are as security-minded as I am so they made sure yaourt can run with user privileges. It just needs to be able to call pacman trough sudo to let pacman take care of the real installation / uninstallation work. If an application on my regular account – which is not the account used for downloading or logging into my X-server, mind you – gets exploited there is not much harm done. The worst that can happen is that it starts installing applications from the trusted arch repositories to my system / uninstalls any applications from my system. Annoying? Yes. Possibly harmful? Yes. But not nearly as bad as what could happen if I had been using my root account or if I had used sudo like an Ubuntu-monkey.
Now as you probably noticed, there are a lot of sections in that sudoers file which I haven’t even touched. That’s because sudo can be configured to allow multiple users to run different apps with root privileges on different hosts all from the same sudoers file. That way the senior system administrator only has to write one sudoers file and configure all his boxes to automatically rsync their sudoers file with the one he edited. Voila, adding a new junior sysadmin to several boxes with different permissions on each box has never been easier. Here’s an example of a more advanced (but still very basic) sudoers configuration in which all configuration options are explained pretty well.
If this guide made you grasp and think “Wow, and I thought I was being SAFE using sudo the canonical way!” my job here is done and you’re on your way to securing your box.
