UnConfusing The Issue Of Disabling Root On Linux or Unix

Hey There,

Loosely following up on a few previous posts regarding securing Linux and Unix and even more fun with Unix and Linux security, today we're going to look at something vaguely security-related, and also vaguely scary ;)

It has to do with the root account (or user id 0) and security hardening. I've got nothing against either, so this won't be an insane diatribe, but (especially, no offense to Ubuntu) with more Linux distro's coming straight out-of-the-box with root disabled, I see the issue of security and the root user get a little confused. A lot ;)

There are a numbers of things at issue here, and they're all loosely tied-together by the common thread of an earnest striving for better total-system security. Today, I'm just feeling like clearing some of them up to the best of my ability, before they make me nuts.

1. Having a disabled root account and removing a root account are two entirely separate things. As I mentioned above, Ubuntu comes with the root account disabled (basically, you can do this on any OS by running "passwd -l root" as the root user, hopefully setting a regular user up with a sudo rule so they can su to root if they need to later, and then exiting out of the root account).

This is perfectly fine. It upsets quite a few people who don't know what to make of it, initially, but it's not a bad idea. The root user's password is locked, so no one can su to it without sudo (or some other privilege-escalation vehicle), but the account still exists and runs as normal.

It goes without saying, at this point in the post, that actually removing root (userdel root will fail - probably too late - but you can accomplish almost the same thing by editing /etc/passwd, /etc/group, /etc/security/*, etc, as root and logging out) is a bad idea. The problem then becomes that, not only can no one su to root, it's actually gone, and everything that used to run as uid 0 will begin to exhibit bizarre behaviour. Without intervention you can expect to lose your system fairly quickly and have the boot process crash on you as soon as it gets to running init, at best. By default, on almost every system I know, init runs as root, spawning "init" (process 1 - the mother of them all). If that can't start, what else can? I've heard tell of systems that will revert to the nobody account to run this, but I've never seen it happen and I can't imagine how it would work...

2. There are ways to run your system without having a root user, but almost all of them are not worth the effort. As a blanket statement, if you replace the root account with another account with uid 0 (Except in such instances as FreeBSD, where they've gone through the trouble of actually coding out a "toor" user as a root variant), you're opening up the door to any number of problems you may have not foreseen. Replacing uid 0 with uid 100034 (pick a number) would be even more probable to cause stress-related fatalities ;) Liken it to the old-style firewall security method of "block what you don't want and let everything else in." That philosophy was eventually replaced by the more sensible "block everything and only let in what you want" method. If you mess with root, or uid 0, you may have a huge list of things you've accounted for, but you're almost guaranteed to stung by something you'd (and anybody else probably would have) forgotten or never even considered.

3. Changing init in Linux using the boot loader (with arguments like init=/bin/bash) doesn't actually address the issue with running init without root, or a user with uid 0. This trick can come in very handy when, for instance, you want to subvert LILO or Grub security and boot into bash. Of course, / will be mounted read-only, but it's only a minor inconvenience to run "mount -o rw,remount" on it to begin editing files you shouldn't be editing. Of course, you'd only end up doing this if you were in it deep and had to manually edit your /etc/shadow file or something, right? Yes. That's the ethical answer :) As far as hardening security goes, I'm not sure how this misconception got started.

4. Having more than one user with uid 0, or more than one group with gid 0, is not only insane, it's lazy-insane ;) Seriously, I've seen this proposed as an alternative to locking root's password and using sudo in order for certain users to access root to make changes as the superuser. There are a few issues with this sort of convenience, none of which are good (except, that 5 or 6 guys on your system have uid 0 and root privilege which is great! ...I mean bad). Aside from the simple "plus 1" factor of risk-of-accidental-keystroke-downing-your-machine incidents per user with said privilege, having multiple users with the same uid and/or gid can cause erratic behaviour with programs that do name-to-uid and/or uid-to-name mapping (like the login command).

All of this comes back to locking up the root user password. This is (assuming you have to pick from that and the 4 options above) the most sane choice. I'm not gonna shine you on about how I've never used root as my main account for years on end and haven't ever accidentally deleted the /dev filesystem (well, at least as much as it would let me before there was no device left to do the deleting ;) I've done lots of crazy and irresponsible things in my career and, according to some folks (like the U.S. military and heavy-hitting banking and/or securities-trading companies) I still do, no matter how good I try to be ;)

But I think, if you must tighten the screws on the root account, then look to Ubuntu's example and have the default setup with a locked root password and a user account that can "sudo su" to it. There's no need to be any more extreme or creative and, if you decide that you must and haven't completely profiled your operating system's kernel and shell code before implementation to ensure safety from latent dependency bugs (or somehow managed to figure out a way to defend against an army of guys/gals with root privilege easily and with guaranteed low-downtime), may luck be with you. And, if it's not, may you have an understanding superior.

Hopefully, this hasn't confused the issue even further. Whatever the issue was... ;)

Cheers,

, Mike