42

This page on server hardening claims:

Disabling the root account is necessary for security reasons.

Why is disabling the root account necessary for security reasons?

psmears
  • 900
  • 7
  • 9
Randomblue
  • 1,685
  • 3
  • 15
  • 17
  • 8
    I believe your answer is in the section just above your quote "Create “shadow user” with sudo powers" – schroeder Feb 15 '16 at 21:07
  • The link is only suggesting that you disable the password for the root account using [passwd -l](http://man7.org/linux/man-pages/man1/passwd.1.html), not that you disable the root account in some sort of greater way. You could still do `su`. – Neil Smithline Feb 16 '16 at 01:22
  • 6
    BTW, I can't say that I think that is a great article. – Neil Smithline Feb 16 '16 at 01:29
  • 2
    If you're running an Ubuntu server, try `tail -f /var/log/auth.log` and see how many attackers try to log in as root. – S.L. Barth Feb 16 '16 at 12:09
  • 1
    An undisabled root account is only protected by its password strength. If that password is compromised, your system is compromised. – Thorbjørn Ravn Andersen Feb 16 '16 at 14:40
  • 1
    And all this essentially reflects that the original security model in Unix of root being omnipotent does not work well in the world of the internet. Finer granularity is needed. – Thorbjørn Ravn Andersen Feb 16 '16 at 14:48
  • 2
    A page on server hardening that goes on at great length about how important it is to secure /tmp, yet manages to confuse /tmp and /var/tmp ([they are not the same!](http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE)) and somehow *not* mention [libpam-tmpdir](https://launchpad.net/ubuntu/trusty/+package/libpam-tmpdir)? While it definitely has some good suggestions, clearly that page should *not* be taken as gospel. – user Feb 16 '16 at 17:45
  • Related, from Unix Stack Exchange: [Which is the safest way to get root privileges: sudo, su or login?](http://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/) – mattdm Feb 17 '16 at 13:45
  • @ThorbjørnRavnAndersen: "An undisabled root account is only protected by its password strength": So, if one disables password login for root and uses instead an ssh key pair, then problem solved! Or is it? – Steve Jessop Feb 17 '16 at 15:27
  • @SteveJessop it is a step in the right direction. You may want to see what Apple has been doing with "rootless" in OS X. http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really – Thorbjørn Ravn Andersen Feb 17 '16 at 20:06

6 Answers6

81

If you're not using Root, you're using sudo! Sudo is a great way to become root only when you need to.

  1. Root is a giant target. What's root's username? Root! I'm so smart :)
  2. Logging. Sudo has a greater command of audit logging (so that when someone uses sudo to do something silly, you can tattle on them to the central logging server). This is helpful for forensic analysis in some cases.
  3. Granular permissions. Root is a Big Flippin' Hammer. Do not hand BFHs to your users. Sudo allows you to specify that a user can run update commands like aptitude without password, but everything is off limits! You can't do that with the BFH that is root. IT allows you the flexibility of sanctioning certain commands for users, but disallowing others. This allows you to build a security policy that does not require an administrator to physically log in to a machine every time a machine needs to be updated (or another menial task).
  4. Idiot-proofing. Why do you not hand users a BFH? Because they're dumb. Why do I use sudo instead of root? I'm dumb. Dumb means mistakes, and mistakes mean security holes and sysadmin-issues.
Ohnana
  • 4,737
  • 2
  • 23
  • 39
  • 19
    Then the user types: `sudo bash` – Tom Leek Feb 15 '16 at 21:19
  • 43
    And if you have a proper audit policy, the user will see: `Permission denied. This incident will be reported.` – Ohnana Feb 15 '16 at 21:20
  • 10
    Then the user types `SHELL=/my/program apt-get install ` and gets a shell because some package has mistaken `$SHELL` for `sh`. – Gilles 'SO- stop being evil' Feb 15 '16 at 21:26
  • 1
    Or the user creates a package with a setuid shell, then installs it. Or install an old version of a root daemon that has known vulnerabilities. – user253751 Feb 15 '16 at 23:56
  • 7
    While you make a good argument for using `sudo` over the root account, I'm not sure that you actually make an argument for disabling the root password. – Neil Smithline Feb 16 '16 at 01:19
  • 3
    @Gilles Unless you only allow updates, or have a white-list of packages. – PyRulez Feb 16 '16 at 02:23
  • @Ohnana you can do all that while having a root account enabled. You only need to disable it if people using your system have to be forced to follow the rules (i.e. they are either stupid or cannot be fully trusted). – Dmitry Grigoryev Feb 16 '16 at 08:05
  • @TomLeek `sudo su` seems to work better, because it sets up the environment correctly, runs a login shell, etc. – user253751 Feb 16 '16 at 08:47
  • 7
    @PyRulez Allowing only updates wouldn't help. However, the default sudo configuration on many distributions where it scrubs most environment variables including `SHELL` does solve *this particular* avenue of escalation. There are probably others involving packages with interactive configuration, though allowing only upgrades reduces the risk a lot there. – Gilles 'SO- stop being evil' Feb 16 '16 at 10:25
  • 4
    @immibis Running `sudo su` instead of `sudo bash` is both irrelevant (Tom's point is that the user runs a shell, after which they can do anything they want) and pointless (`sudo su` does not “set up the environment correctly” any more than `sudo bash` does, and does not run a login shell — it runs the user's login shell (`pw_shell` field of the user database), but not as a login shell (`-bash` or similar that will run `.profile`)). – Gilles 'SO- stop being evil' Feb 16 '16 at 10:28
  • 7
    My only quibble with this is the use of the term "idiot-proofing". One can make a system fool-proof, but only idiot-resistant. True idiot-proofing is impossible, because the Universe keeps manufacturing better idiots. – Monty Harder Feb 16 '16 at 15:57
  • It could be argued that using a dedicated root account and always starting a root shell is more secure than `sudo`, because `sudo` either caches credentials (allowing a malicious program to hide in the background and ride in on the coattails of a legitimate request), or requires you to type your password so often it becomes a habit. – Simon Richter Feb 17 '16 at 14:29
  • @Gilles @immibis the implication is that the user could be malicious, in which case using `sudo` is not an option –  Feb 17 '16 at 15:38
  • @immibis, `sudo su` does nothing that `sudo -i` doesn't, other than needlessly call unnecessary executables. – Charles Duffy Feb 17 '16 at 18:56
  • So why don't you rename root? – Joshua Feb 17 '16 at 19:17
  • 1
    @Joshua that is an incredibly hard thing to do, and will most likely haunt you for the rest of the system's life. Everyone depends on root! It's best to disable login and work from there. – Ohnana Feb 17 '16 at 19:32
  • @Ohnana: vim /etc/password is easy. Files are owned by id not by name. – Joshua Feb 17 '16 at 19:33
  • @Joshua /etc/shadow, /etc/groups too. Plus, `find /etc -type f -exec grep -l root {} +` is how many configuration files look for root as root and not UID 0. And that's not counting all the tools you might have to recompile for the new system configuration... In a perfect world, everyone would say UID 0 instead of root, but those damn meatsacks keep munging everything up. – Ohnana Feb 17 '16 at 19:39
  • You are neglecting the fact that I've tried it with success. – Joshua Feb 17 '16 at 19:43
  • Biggest reason for sudo over root login for me: if you need to give root access to multiple people, then want to revoke it for one person (eg, he or she leaves the company). With sudo, easy. If you handed the root password to these people, you need to change it and everyone else needs to memorise the new password. – thomasrutter Feb 18 '16 at 04:20
  • 2
    @Ohnana [This incident will be reported](https://xkcd.com/838/) indeed. – gerrit Feb 18 '16 at 09:33
38

The site you link to is very poor at explaining what they are getting you to do. The root account is not being disabled, but rather, the password for root is disabled. That's what passwd -l does.

The intent of those instructions is to make it so that people cannot log in as the root user, because the root account is easy to guess. I'm not sure that their approach of creating a pseudo-user with a "hard to guess name" will be that much more secure ...

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 1
    root is indeed the main target of ssh bots. Should you forget to disable it in `sshd_config`, the OS would back you up. – edmz Feb 16 '16 at 15:40
17

It is an old Tradition from the days of the Mainframe. The idea is that root can do what he wants with the machine, including replacing the kernel or destroying the UEFI variables, which can brick the machine. Whereas a non-root account cannot -- unless that account is given administrative rights through sudo, which is what you will have with Ubuntu, and it totally destroys the rationale above.

Really, disabling the root account is now used exclusively to appease elder gods, who:

  1. are grumpy;
  2. are obsolete;
  3. have been dead for decades, but are still worshipped by a powerful caste of high priests, collectively known as "conformance auditors".

In practice, your digital life is completely accessible from your normal user account, so making any protection relative to the root user does not make a lot of sense. Mucking with the root/non-root distinction is a thing of the past, when machines were big servers shared between hundreds of users who were possibly hostile to each other.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 19
    "your digital life is completely accessible from your normal user account" - OP is asking in the context of *server* hardening. This presumes a desktop system. – Kevin Feb 16 '16 at 00:53
  • 4
    Also, `sudo` logs stuff, I believe. – PyRulez Feb 16 '16 at 02:20
  • 7
    There is an accountability aspect when on multi-user machines. Root is a generic account, so anything done by root can't be tied to a user (unless the login was elevated from a specific user account). – Jozef Woods Feb 16 '16 at 05:56
  • 2
    Is this answer tongue-in-cheek? Or do you also still use password authentication instead of keypairs? – aross Feb 16 '16 at 14:07
6

Please be aware that (at least on Ubuntu and its derivatives), there is a tradeoff involved with disabling the root password.

Should there be a disaster on your system, you will want to boot the system into recovery (or single-user) mode from the console. If the root password is disabled (as it is by default), then no authentication whatsoever can be required when booting into single-user mode, because the root account has no credential to be used for this purpose, and no other account can be guaranteed to work under those circumstances. This is handled by special-case code in the sulogin program.

On balance, though, this is an easy trade to make: you are preventing a whole class of remote attacks while opening up the system to unauthenticated root login from the physical console. Remember that you cannot ever secure a system from an attacker with physical access to it anyway. This is why secure data centers with electronic access controls exist.

Mike McManus
  • 1,415
  • 10
  • 17
2

Root is generally disabled to provide an extra layer of security throughout the Linux operating system. The root user has the ability to change literally anything no matter the importance. This makes it a common target of hackers, viruses, etc. Disabling it (or rather disabling the password) ensures that the account cannot be logged into if the password is retrieved (not actually that hard to do).

Alexander C. Solon
  • 21
  • 2
  • 2
    Actually, it can be quite difficult to "retrieve" a complex root password on modern Linux systems, notwithstanding basic user mistake. – Stephane Feb 16 '16 at 12:02
  • There's always the brute-force methods, or if they use a password with any sort of word in it, a rainbow table could be used. Either way, it's possible to do so, and if you're running a server that could be a popular target (say a server for Google, Facebook, or something) it would be best to ensure that it wont happen anyways – Alexander C. Solon Feb 18 '16 at 02:13
  • It depends on the config, but good luck on brute-forcing a complex root password that has been stored with bcrypt. And since passwords are salted (in pretty much all possible configuration, including most default), rainbow tables are useless. – Stephane Feb 18 '16 at 06:53
0

By default, the root account password is locked in Ubuntu.

Because If that user's account is compromised by an attacker, the attacker can also gain root privileges the next time the user does so. The user account is the weak link in this chain, and so must be protected with the same care as root.

The root account password does not need to be shared with everybody who needs to perform some type of administrative tasks on the system .

To disable your root account use the following command:

sudo passwd -dl root
GAD3R
  • 2,211
  • 3
  • 15
  • 38