33

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?

thepocketwade
  • 1,525
  • 5
  • 16
  • 27

10 Answers10

43

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.

Dan Carley
  • 25,189
  • 5
  • 52
  • 70
  • 1
    Could you flesh out why the remote root login is a "reasonably big vulnerability." – thepocketwade Jul 20 '09 at 17:31
  • 5
    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. – Shalom Craimer Jul 23 '09 at 11:35
  • 2
    Another advantage of sudo: Logging of executed commands. – Manuel Faux Jul 28 '09 at 08:32
  • That's auditing ;) – Dan Carley Jul 28 '09 at 08: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. – TJ L Sep 28 '09 at 18:27
  • +1 for auditing. Which in my book is about the only reason not to login as root. – JamesBarnett Jan 01 '11 at 01:19
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. :)

egorgry
  • 2,871
  • 2
  • 22
  • 21
15

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.

Tim
  • 1,879
  • 3
  • 18
  • 16
10

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

Jure1873
  • 3,692
  • 1
  • 21
  • 28
  • 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
  • How do you get a subshell from inside vim? – thepocketwade Jul 22 '09 at 14:37
  • @Jure1873: thanks for the help with http://serverfault.com/questions/43458/ (sorry for the superfluous comment - there's no other messaging system on SF...) – Shalom Craimer Jul 23 '09 at 11:37
  • @thepocketwade, type :!bash – lfaraone Jul 27 '09 at 15:25
9

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.

Zenham
  • 622
  • 5
  • 11
4

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.

mibus
  • 816
  • 4
  • 5
  • 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: http://www.ibm.com/developerworks/aix/library/au-korn93/?S_TACT=105AGY06& – Mei Jul 17 '09 at 00: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 04: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 02:48
1

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.

chris
  • 11,784
  • 6
  • 41
  • 51
0

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

Johan
  • 795
  • 2
  • 7
  • 13
0

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!

Aiden Bell
  • 609
  • 1
  • 5
  • 15
-2

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 *)

gizmo
  • 1