"John M. Brown" wrote:

I have question for the security community on NANOG.

I confess that I think of NANOG as not being a security community, rather it is a group of north american network operators. That said, you can find all sorts of info for the somewhat naive question below by a slightly judicious use of our friend, Google. That said, and since I'm avoiding work that I SHOULD be doing, I will answer your Important question.

What is your learned opinion of having host accounts (unix machines) with UID/GID of 0:0

This shows a certain naiveté, and suggests that you have not heard of truly useful tools such as sudo. If it's UNIX, sudo builds. Why is this a bad thing? The first number in your password entry implies USER. Not users. There is simply no way to tell which of many multiples of people might have made a change in your system, since the UID is the same for all.

otherwords

jmbrown_r:password:0:0:John M. Brown:/export/home/jmbrown:/bin/mysh

I also truly hope that this was just a quick copy by you, and that you are not truly discussing a system here that allows the password file to actually contain the password. Please tell me that your password file is at least shadowed, and that was just a typo.

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.

I will also supply you with a bit of advice, one that I see even using SSH over the network to my own machines: "Don't login as root, use su"

Now, don't flame me over the question, but provide valid pro's or con's for this practice from your experience.

There are no positive aspects to this practice. I suggest that you get the wonderful red book (now colored purple, last I recall) by Evi Nemeth et al, and study it thoroughly. I now return you to the discussion on (wireless and other) security, how much is too much, and so on. -- ...some sort of steganographic chaffing and winnowing scheme already exists in practice right here: I frequently find myself having to sort through large numbers of idiotic posts to find the good ones. -- Rufus Faloofus

-----BEGIN PGP SIGNED MESSAGE----- Hash: MD5 Hello John, Sunday, September 22, 2002, 6:22:11 PM, you wrote: JMB> I have question for the security community on NANOG. JMB> What is your learned opinion of having host accounts JMB> (unix machines) with UID/GID of 0:0 I'm not sure my opinion is learned, but I would say it is a bad idea. The vast majority of users do not need all of the privileges that root access provides. The reason that *nix systems have different users and groups is to give them different levels of access. In addition, if there are specific programs that need to be run by a user which require root access and administrator can use sudo (http://www.courtesan.com/sudo/) to give faux root access, without having to divulge the root password. JMB> The argument is that way you don't hav to give out the root password, JMB> you can just nuke a users UID=0 equiv account when the leave and not JMB> have to change the real root account. That is an invalid argument for three reasons: 1. As soon as a user leaves an organization, their accounts should be deleted -- that should be SOP at all companies. If you do not allow the root account to connect directly (ie you cannot SSH to the server directly as root -- you have to connect as another user and su) when you delete the user's account they cannot gain root access. 2. You should be rotating your root password often enough that users would be accustomed to a password change. 3. The only users who should be able to gain root access to a system are those in the root wheel, at the very least accounts in the root wheel should be monitored closely and rotated in and out of the wheel as necessary. Hope this helps. allan - -- Allan Liska allan@allan.org http://www.allan.org -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUAPY5Jl3+n87oa5a9VAQHB+AQAhv2sIrAqs0HPUqYPWKxFheDk97lya1fs fS9XZ07mJ+M0Lds0PzDC8k2GL8T8hQrOaCeMckkE9+ssP5SuqVY/bZqGGsltkz79 o7/lT24BE+lpLFXVYddFQaUa9DH1i1wDtpigBxY1PJI014ZRViSS51ydz1X8RBvQ 4Zprc4g6tGo= =Y2iu -----END PGP SIGNATURE-----

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