North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Security Practices question
- From: Barb Dijker
- Date: Mon Sep 23 11:51:37 2002
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:
Learned opinion is, it is considered a back door. Period. It's bad enough
having to have one login like that.
What is your learned opinion of having host accounts
(unix machines) with UID/GID of 0:0
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
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
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.
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.
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.