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?
asked Jul 16, 2009 at 20:41
-
2Are you thinking of ssh logins or also logins from the physical machine?– TelemachusJul 16, 2009 at 21:27
Add a comment
|
10 Answers
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.
answered Jul 16, 2009 at 20:46
-
1Could you flesh out why the remote root login is a "reasonably big vulnerability." Jul 20, 2009 at 17:31
-
5Because 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. Jul 23, 2009 at 11:35
-
2
-
-
1While
sudois superior,sualso allows you to use the-mflag to keep the environment variables the same while in a root terminal. Nothing drives me more bonkers then tosuto root for a bit, only to do something with~in the directory name and have it not work.– TJ LSep 28, 2009 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. :)
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.
-
1After someone has run su - root, how do you determine what commands they ran? Is this logged somewhere? Jun 17, 2011 at 3:28
sudo also automatically logs every command to syslog and you can define the commands each user can user.
-
3As 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).– ZenhamJul 16, 2009 at 21:14
-
2Indeed,
sudo vim foo.txtthen drop to a shell from within vim will give you a root shell without the regular sudo logging.– OphidianJul 16, 2009 at 21:18 -
-
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? Jul 20, 2009 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.– Jure1873Jul 21, 2009 at 21:07
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.
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.
-
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. Jul 16, 2009 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/…– MeiJul 17, 2009 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'.– derobertJul 17, 2009 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.– mibusJul 18, 2009 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.
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).
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!
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 *)
