Security Practices question

Wed Oct 2 21:57:48 UTC 2002

On Wed, Oct 02, 2002 at 05:08:05PM -0400, woods at weird.com said:
> [ On Wednesday, October 2, 2002 at 13:26:15 (-0700), Scott Francis wrote: ]
> > Subject: Re: Security Practices question
> >
> > grr. Please read Barb's post about exactly why multiple aliases for the
> > UID 0 account is a Bad Idea. It's not really about opening potential
> > security vulnerabilities as much as it is about bad (lazy) administration.
> 
> I've been doing Unix systems security analysis and design and
> development at least as long as Barb has, and maybe even longer.  I do
> know what I'm talking about -- in very great detail even.  I know Barb
> reasonably well on a professional level (though we haven't talked in
> several years), and I didn't have any major objection to the things she
> said in her recent post.  She was not anywhere near so adamant about
> things that do not matter as you apparently are.

It's my opinion that security, especially when throwing around accounts with
unlimited privileges on a system, matters. If you think differently, well,
you have a right to that opinion as well.

Apparently I will have to quote verbatim from her previous post.
----
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.
----

That seems pretty clear to me as a denunciation of the entire idea. If you're
interested in hearing her specific points, they were as follows:
----
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.
----

Barb goes on to describe tested behavior on various *nix systems from having
multiple uid 0 accounts. Again, I suggest you read over her original post
more carefully, rather than merely using your experience in system design and
your relationship with her as a foundation for your argument. You claim that
you know what you're talking about - I'm not disputing this claim. I'm merely
asking for some evidence to support your position on the issue of multiple
uidzero accounts. So far you have used the "I've been doing this a long time"
argument, the "familiarity with $authority" argument, and some (still)
unsubstantiated claims about sudo's inadequacy/insecurity.

> Perhaps you don't understand the threat model here.  Just because there
> are multiple UID==0 accounts doesn't mean they're used all the time by
> ordinary users for ordinary uses.

What difference does it make how often such an account is used? How does that
have any bearing on this discussion at all? Whether the account is
legitimately used daily or once a year, the fact that it _exists_ at all is
the threat. (And I would certainly hope that ordinary users are not running
around logged in with superuser privs all day long for ordinary uses.) Every
account with uid 0 is another way for an attacker to enter the system - or
for a user/admin to make a mistake. Instead of having one point of entry (one
root password) you now have N+1 points of entry (where N is the number of
non-root uidzero accounts that exist with valid shells).

> However you cannot _not_ use 'su' without multiple UID==0 accounts (assuming
> you have multiple superusers and want at least some semblance of an audit
> trail).

Trying to follow your logic here, and failing. Any users on a standard *nix
box in gid 0 (wheel or the equivalent) can use su to become root (or another
user). Every time a user executes 'su' it's logged in /var/log/messages or
the equivalent. If you're driving at the fact that what they do _after_ that
'su' is not logged, you're right - but neither is it logged if you're using
a non-root uidzero account (not unless you have hacked your system logging
facility to trace such activity, and if you have, you're imitating sudo
functionality.)

You don't want multiple superusers (there really is no such thing, anyway -
it's all root, regardless of the alias you put to the uid). Basically ... use
sudo. again.

> Multiple UID==0 accounts mean each superuser can login directly as a
> superuser without
> having to have their "normal" account be privileged in any way, and
> as a bonus they can, if their system supports it, get a trusted path for
> that login, something that's not so easy to ensure for 'su' et al.

Gee, that sounds like sudo. Except with sudo, I can make it so that each user
gets _only_ the privileges he/she really needs, rather than full run of the
system (including the ability to change root's password - but then that's
already been done by adding another password to the uid 0 account). There is
_no material difference_ between logging in as root and logging in as some
other user with a different name, but the same UID. It's just window
dressing.

> I.e. your claims are where the rubbish lies.  :-)
> 
> > Can you back up that statement in /any/ way? What exactly are your reasons
> > why sudo is a worse solution (or even a bad idea)?
> 
> Sudo is only useful and safe to use in a very narrow range of
> applications, a much narrower range than almost anyone else I know of
> who advocates it, including its authors and maintainers, realalizes.

You haven't mentioned ANY examples yet. I'm beginning to think you have no
data with which to backup your statement. The very fact that you're arguing
that 'sudo is only useful and safe to use in a very narrow range of
applications' on the one hand, and then advocating handing out full uid 0
privileges under various aliases and passwords on the other hand, makes my
head hurt.

> There is a wealth of documentation available online showing the foibles
> and problems with the likes of 'sudo'.

Please provide some concrete evidence to backup your claims. I have. If
you're referring to the security hole in sudo from several months back, well,
I direct your attention to /bin/login and various other system utilities,
essential and not. All software has bugs from time to time. sudo's track
record is fairly solid. If you can _demonstrate_ otherwise, please do.

So far you have given no concrete examples of why anybody should not use
sudo, or why anybody should allow multiple uidzero accounts on a system.

I'm probably beating a dead horse here; those who were willing to be
convinced by arguments pro and con already have been, and those who will
never change their minds won't do so on the basis of more posts by me. I'll
continue this off-list; apologies for perpetuating yet another off-topic
religious debate.
-- 
-= Scott Francis || darkuncle (at) darkuncle (dot) net =-
  GPG key CB33CCA7 has been revoked; I am now 5537F527
        illum oportet crescere me autem minui
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20021002/aa5395d9/attachment.sig>