Why su to root instead of logging in as root?

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.

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.

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

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.

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