North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Security Practices question

  • From: Barb Dijker
  • Date: Mon Sep 23 11:51:37 2002

Hi John,

Haven't seen you in a while. I hope all is well. Maybe I'll make it to a nanog or arin meeting again one of these days.

As these are unix security questions and I've been a principle reviewer of the bible on unix sysadmin (by Ms. Nemeth et al)...

At 03:22 PM 9/22/02 -0700, John M. Brown wrote:

What is your learned opinion of having host accounts
(unix machines) with UID/GID of 0:0
Learned opinion is, it is considered a back door. Period. It's bad enough having to have one login like that.

On all the machines I manage, the (one) uid 0 account is never used. Period. In fact my staff don't routinely even know the root password. If root ever logs in, it is considered a breach. There is no need for it and I've yet to have anyone convince me otherwise in 15 years of doing this. The only time one needs to login as root is in single user mode when the system won't boot otherwise. For that, the root password is written in a sealed location known to all who need to know. If the seal is broken (meaning it was used), the password is changed.

The problems are specifically:

1) Accountability. You don't know who is creating files and running processes. The best you might get are timestamps and source IP on things like wtmp and su logs for gross comparisons. That's not good enough in most cases.

2) How do you know that all programs protecting the "root" account always do so by UID rather than username? That is unless you view the code yourself or test all such mechanisms. E.g., sshd or login that prevents the root account (usually by default) from being logged into directly from the network interface. How about su where you are supposed to be a member or group 0 before you can suid to root? What about home grown code? It would be nice to think everyone was a good little programmer, but you don't know until you actually test every one of those protective mechanisms.

3) There can be unusual and unexpected behaviors. Some may be benign and confusing, others a problem. For example, all the files will appear as owned by "root" in 'ls' regardless of which of the uid=0 users created them (file ownership is stored by uid). See accountability above. Worse yet, your root files may appear as owned by jmbrown_r. It all depends on how your system reads the passwd database as to which name "wins." What home directory is used when a program needs to reference the users' home directory?? You better test this on your rmuser/userdel program, otherwise you may delete your real root home directory when you delete the other users.

4) Have you ever renamed the root account to something else and left it uid 0? Some of us have been unfortunate enough to have this happen by mistake (by someone who shouldn't have had root access). You would be surprised at what it breaks. Try this first.

The bottom line is that the behavior is OS dependent. For example, I just tried this on BSDI and Linux. The BSDI box was pretty well-behaved by maintaining the proper (original) USER environment after su (even su -). On the linux box, once logged in or su'd the account was 100% indistinguishable from root in all respects. However, su without the - option left some original env vars, but not important ones. Using the 'passwd' command changed the password on the root named account, not the user that logged in on Linux, but not BSDI. However, the BSDI box showed jmbrown_r as the user for all root files using 'ls', the Linux box didn't. The behavior between the two OS was completely inconsistent.

In sum, alternate uid=0 accounts are not necessary, problematic, and have OS dependent behavior. So if you are forced into providing them, you should first test each OS on which you are forced to do this. And test thoroughly.

The argument is that way you don't hav to give out the root password,
you can just nuke a users UID=0 equiv account when the leave and not
have to change the real root account.
Specious. The counter argument is that you actually HAVE given out the "root" password. The definition of the "root" account is any account with uid=0. The username is not used for determining unix permission levels - which is of course the whole reason you want uid=0. All you've done is associated multiple passwords with _the_ only root account. That just makes it easier to crack. You've also made it possible for many people to change the "root" user password without them even realizing it. That will be fun when your system is toasted and you have no clue what the root password is. Single-user mode won't accept jmbrown_r's password.

If the users to whom you've given such accounts are naive enough to believe that argument, that they don't have the "root" password, they may also be naive enough to share it with their buddies.

There is often an argument that goes something like sudo doesn't fully change all of the user attributes, and that's not enough in some cases. Given that in most environments you can't login as uid=0 regardless of the username, you would su, then the uid=0 accounts (on a well-behaved OS) may not give you any more fully root access than does sudo.

I suspect the reason you are asking this question is because you have someone who is well-respected insisting that it is a reasonable practice. And you must convince your colleagues otherwise with technical information rather than, "s/he doesn't know what s/he's talking about."

BTW, sudo is not a panacea either. It should not be given to anyone you wouldn't trust with the root password. That's because there are too many programs in which you can break out into a shell or otherwise do something unintended. A combination of sudo and suid/sgid wrappers usually does the trick. A well-written wrapper that limits access (e.g., by group) can be preferable to sudo in many ways.

There may still be some (brain damaged imnsho) applications that absolutely insist on being installed as or operating as fully both uid=0 and euid=0. If installation is the only problem, then it should be installed by one who has the root password, because it is going to do something to mess up your OS config anyway. If it wants to operate that way, may *insert deity* help you. Try to talk to some of the app engineers to find out what it needs it for. You might be able to set it up to run in a chroot environment or you might help them find a way to wrap it or run it as a different (uid != 0) user. Often it is really group access it needs, kmem and maybe sys or disk on linux.

Concede only under duress.

...Barb