Security Practices question

Mon Sep 23 15:49:20 UTC 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