How to use sudo (and why ubuntu sucks) [Published]
Amie
Regular
Sudo - How it should and should not be used
(And why Ubuntu sucks)
I love sudo. Yet at the same time I hate the Ubuntu-trend of disabeling the root account and give the first user full root priviliges trough 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.
What is sudo?
Sudo - superuserdo - is an application which temporarily elevates the priviliges of a regular user account to root priviliges. This allows a user to run applications or commands with root priviliges, 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 priviliges, or to allow anything and everything which has "sudo" in front of it to run with root priviliges.
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 priviliges. 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 priviliges (and you're sure the application can be trusted and there is no way to do what needs to be done without root priviliges) you can allow that application to run with root priviliges, and only that application. That way the damage which can be done trough an exploit of the application is minimised; 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 priviliges, even though it runs from a regular account. If you do not trust an application, do not run it with root priviliges, 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 priviliges. 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 priviliges, 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.
Why ubuntu sucks
If you've paid attention, you now realise 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 prviliges, 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 priviliges. 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 priviliges.
Quick intro to sudo configuration
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 [COLOR="DarkOrange"]# Set default editor to nano: Defaults editor=/usr/bin/nano, !env_editor[/COLOR] # Runas alias specification # User privilege specification root ALL=(ALL) ALL [COLOR="DarkOliveGreen"]amie ALL= /usr/bin/pacman[/COLOR] # 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 priviliges. 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 priviliges 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 priviliges. 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 priviliges 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 eplained 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.
Comments
As far as disabling root user goes, I disagree with you. Your method adds unnecessary complication and provides ZERO extra security. All a hacker would have to do it log your root password and then all of a sudden he has full administrator rights. Because you don't use sudo the hacker is just as likely to get your root password as he is your ordinary password.
With the root user disabled a hacker can only gain access to the less dangerous user. Password logging is a security issue no matter what you do, it cannot be avoided. Canonical is in the right. Ubuntu is a great operating system. You are working under false pretences. There is absolutely no reason not to use sudo and %wheel, it allows escalated commands, logs everything you do and forces for a password (I do agree the 15 min time allowance is too long. You can probably change this though...).
If you really wanted to be secure you would only enable sudo for users logged into the machine physically (not over ssh).
"My method" (the way it was actually intended to be done, not my invention) is perfectly valid if you only use the root acount for console login. That way the root password cannot be recorded without compromising the root account first / physically accessing the box (and when a hacker has physical access you've already lost the battle). Anything which needs to be done over SSH is done with sudo. Suddenly need more permissions on a remote server? Edit the master sudoers file (again, from a console on the master server which is accessible) and you've got 'em.
"My method" is also valid on an ubuntu desktop, because just about any ubuntu user uses his administrator account as a regular user account ('cause I'm not using the root account so I'm safe, right? right?). Using "my method" you use the root account - from a console - for administration and the user account for using your computer.
Again, THERE IS NO SUCH THING AS A LESS DANGEROUS USER IN A DEFAULT UBUNTU INSTALLATION! Access to an account with full sudo permissions is exactly as dangerous as access to the root account. Unless you've edited your /etc/sudoers file, your administrative user has full sudo permissions. And unless you use your administrator account only from a local console - and if you do, why not just use the root account? - that password can be logged super easy.
But it still adds no more security. Logging in from a console is just you being careful. The fact that you logged in on another tty is reason you are secure. Not that you don't use sudo.
If I logged in using my user account under another tty and then used sudo I'd be protected too.
It has nothing to do with sudo, that's just being careful.
Also, I'm already half way there by knowing the user on your computer with all the rights. He is called root and, assuming you have ssh enabled I just have to guess/brute force his password.
On Ubuntu I have to guess the password AND the username if you're coming in from an outside attack.
There are advantages and disadvantages. But just because Ubuntu and OSX have them disabled by default doesn't mean they suck. They've being safety minded.
https://help.ubuntu.com/community/RootSudo
Only if you don't use that same account for web surfing, torrenting, logging into your X-server ...
Please read my posts carefully. The problem is that a normal acount is used as root user. If you use your administrative user only as administrator, then you're basically doing the same thing, you just don't call your root account root. If you use a normal user account, which you use for web surfing etc. also as your administrative account, you're using an account which may or may not be riddled with exploited applications and which may or may not have a keylogger running as soon as you log into that account - be it from a console or in X.
First, disabeling root access overh SSH is unix security 101. Second, guessing the password is avoided by using a strong password, brute forcing attempts should warn you because they fill your log with failed login attempts. A strong password will not be brute forced before the sysadmin has taken precautionary measures (like suddenly remembering unix security 101 and disabling SSH root login when he sees the brute forcing is underway).
Sudo allows the walls of this garden to be broken out of and is therefore a security concern. The correct usage of sudo is to only permit certain holes to certain users on certain machines.
Agreed. Though, I'm reading around a lot on the issue. It seems to be quite the debate.
CMS Status: