Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've heard often that it is better to su to root rather than log in directly as the root user (and of course people also say that it's even better to use sudo). I've never really understood why one is better than the other(s), insight?

share|improve this question
2  
Are you thinking of ssh logins or also logins from the physical machine? –  Telemachus Jul 16 '09 at 21:27

10 Answers 10

up vote 40 down vote accepted

The inference is to only su or sudo when required.

Most everyday tasks don't require a root shell. So it is good practice to use an unprivileged shell as your default behaviour and then only elevate to root when you need to perform special tasks.

By doing so you are reducing scope for dangerous mistakes (bad scripting, misplaced wildcards, etc) and vulnerabilities from any applications that you use. Especially those which connect to the Internet - see the old adage "Don't IRC as root".

sudo is often recommended because it allows you fine grain and audit the use of such privileges.

By observing these practices you are also in a position to disable remote root logins. This increases the bar of entry for any would-be attacker, as they would need to compromise both a regular user account that was a member of the "wheel" group and ideally only authorised by SSH public keys, then the root account itself.

share|improve this answer
1  
Could you flesh out why the remote root login is a "reasonably big vulnerability." –  thepocketwade Jul 20 '09 at 17:31
4  
Because given that the whole world knows the username ('root'), it's just a question of figuring out the password. And they can do that by brute force and take over your computer. –  scraimer Jul 23 '09 at 11:35
2  
Another advantage of sudo: Logging of executed commands. –  Manuel Faux Jul 28 '09 at 8:32
    
That's auditing ;) –  Dan Carley Jul 28 '09 at 8:34
1  
While sudo is superior, su also allows you to use the -m flag to keep the environment variables the same while in a root terminal. Nothing drives me more bonkers then to su to root for a bit, only to do something with ~ in the directory name and have it not work. –  tj111 Sep 28 '09 at 18:27

You should disable root access from remote so an attacker can't compromise root without first compromising a user then escalating to root. We enable root access at the console only.

Plus it creates accountability. :)

share|improve this answer
    
+1 short and to the point –  lexu Jul 17 '09 at 6:59

The main reason is to create an audit trail. If you need to log into a system as a regular user and then su, it is possible to trace who is responsible for given actions.

share|improve this answer
    
After someone has run su - root, how do you determine what commands they ran? Is this logged somewhere? –  Dobes Vandermeer Jun 17 '11 at 3:28

sudo also automatically logs every command to syslog and you can define the commands each user can user.

share|improve this answer
3  
As for the logging: This is the case for every command preceded by 'sudo', but in the case where sudo is used to elevate to a root shell, commands are only logged in the traditional areas (specifically shell history). –  Zenham Jul 16 '09 at 21:14
2  
Indeed, sudo vim foo.txt then drop to a shell from within vim will give you a root shell without the regular sudo logging. –  Ophidian Jul 16 '09 at 21:18
    
Or just sudo -i to get an interactive session... –  Kamil Kisiel Jul 16 '09 at 23:34
    
I don't understand the problem with sudo vim foo.txt. I ran that, then exited vim and still was myself, is there something I'm missing? –  thepocketwade Jul 20 '09 at 17:35
    
you can "trick" sudo to give you a shell by typing sudo su - or sudo vim and then go into a new subshell. But if you use sudo because you want to have everything logged in syslog (centralized) and you're aware that it can be also used to get another subshell then I don't see anything wrong with it, it's just a bonus as long as i don't depend only on it. –  Jure1873 Jul 21 '09 at 21:07

The idea is to disable root login, and therefore don't have a default admin account. That way a attacker must guess both username and password (and not just the password).

share|improve this answer

Another good reason: When elevating to root via sudo a user authenticates with their own credentials, meaning that they don't necessarily have to be given the root password, making it easier to lock things down when someone leaves your organization.

share|improve this answer

If you are using root on a regular basis then your permissions may be wrong or you may need to grant sudo rights or a new group rights to r/w/x the files or directories.

Good permissions schemes are something even long-time Linux users get wrong, or don't realize the scope they have.

Don't even get me started on what Ubuntu did!

share|improve this answer

If you want to create an audit trail, and don't want to fall victim to the "sudo su -" or "sudo vim foo.txt" problems mentioned here, you can use "sudosh". Hand out root access via sudo, but make the only allowable command to run "sudosh".

sudosh is a logging shell, and you can replay the whole terminal session at a later date, showing exactly what the user saw on their terminal.

share|improve this answer
    
That's assuming of course that sudosh is available on the system. I just checked and I don't have it on any of my Linux boxes. –  John Gardeniers Jul 16 '09 at 22:10
    
You can also use the new ksh93 with audit trail logging enabled. Check this article at IBM developerWorks: ibm.com/developerworks/aix/library/au-korn93/…; –  Mei Jul 17 '09 at 0:12
    
Fairly easy to bypass by just running a shell script (which you then wipe afterwards). Create the script under an innocuous name as a non-audited user (or scp it up from your workstation), then sudo and run it. You could even really hide it by naming it 'ls' or somesuch and putting it in $PATH (altering $PATH if need be), and make it do its dirty work while invoking /bin/ls so it looks normal. Wipe it afterwards. The audit log won't know that /home/anthony/bin used to contain an 'ls'. –  derobert Jul 17 '09 at 4:26
    
Yes, it's not perfect; we know this - but it's a darn site better than plain "sudo su -" IMHO. And yes, it's not installed by default anywhere AFAIK. It does however run on Solaris and Linux fairly readily. –  mibus Jul 18 '09 at 2:48

You should practice security in depth.

Disallow remote root access (or at least root access via passwords). (if you allow root access via keys, carefully control those keys, or better yet use something like kerberos that allows centralized revocation of keys).

I'd disable su and use sudo. That way, users use keys (preferably encrypted) to access the system then they use their password only for privilege escalation. You can restrict which programs people access with sudo, but mostly you just restrict access to who knows the root password.

In an ideal world, you should be able to publish your root passwords on the internet and it wouldn't matter, even if you gave people access to your machine (but didn't put them in the /etc/sudoers file). Of course, you shouldn't publish the root password, but the idea is that you protect your systems with concentric layers of protection.

share|improve this answer

It keeps you from running rm -r -f / I just ran that 2 days ago (as an unprivileged user, i meant to run rm -r -f *)

share|improve this answer
    
The accepted answer already had all the information in it. –  Theuni Dec 8 '12 at 22:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.