Yesterday, Benjamin Scott gleaned this insight:
Ok... I've cooled down, so I'll take a stab at this one...
As usual Ben, you raise a lot of good points. Addressing them properly
requires going into WAY more depth than can reasonably be expected...
Ultimately, this e-mail forum is NOT a good forum for having a discussion
of this depth.
You and I both know that there are answers for everything you say here,
but going into depth on them is impossible... Much better to point the
reader at specific references on network security, which I'll do at the
end of this message.
> And if you're depending on desktop workstations to remain secure simply
> because the user "doesn't know the root password", you *deserve* to get the
> boot when it comes.
Nevertheless, root password control IS essential. At the very least, it
prevents an engineer from doing something really stupid like cd-ing to /,
forgetting that they did, thinking they are in their home directory, and
doing an rm -r *. At MOST shops (obviously there will be exceptions), an
average engineer won't be able to recover from this on their own. I
worked in a building filled with proof of concept for about a year. We
had maybe 3 out of 100 engineers that could do it.
There are other problems that this HELPS solve, and the bottom line is
it's one hole that you've plugged.
>
> Anyone who has physical access to the machine already *has* effective
> superuser access. Don't use simple host trust relationships in any
> environment that isn't physically locked down as tight as a drum.
On most systems, it can be made so that it requires a significant amount
of work to get root access. Even on Linux systems for example, one can
set the BIOS not to boot from the floppy or the CD, and then place a BIOS
password on the system, and lock the case shut with some sort of locking
mechanism.
And yeah, I know all this can be circumvented, but it takes WAY more time
and effort than an engineer just trying to do his job is going to make.
If this is circumvented, you know the guy who did it is serious about
compromising your security.
You hope that these measures would slow down a serious on-site threat long
enough for you to discover them.
It's very likely that when this happens, it's NOT the engineer who uses
that machine who's doing it. It's someone else who wants to steal or
destroy stuff.
> I think you place *way* too much trust in that simple alphanumeric string
> that is the root password. You seem to imply that unlimited, unchecked "sudo"
> access is fine and dandy,
You KNOW that's not true. Unlimited sudo is NOT fine and dandy, and
should only be given out when absolutely essential. We've already said
that it adds an added level of accountability.
> but that knowing what the string in /etc/shadow was hashed from will
> blow you out of the water. At the same time, you seem to imply that
But you need to be root to see that hash. We've already said we don't
want that to happen unless it's absolutely essential. This is one of the
reasons. Ideally, development machines don't participate in NIS, and have
different passwords for all users, including root, than the production
machines.
> > Anyone have a Palm Pilot they sync with their system at work? It's simple
> > for root to access those files, copy them somewhere else and install them
> > on another pilot elsewhere.
>
> That's right. And, of course, the admin staff *does* have the root
> password.
Yeah and that *IS* a concern! But you have to trust someone... by making
sure only the sysadmins have it, you limit that. We've used the UC
Boulder sudo scenario in this and numerous other arguments. So actually
the sysadmins DON'T need root, far more often than not. But there does
have to be a root password. Someone needs to know it, even if it is just
written on a scrap of paper and stored in a safe. So you could limit it
to one or two sysadmins, and use sudo exclusively.
> I find that, in many cases (note: many != all != most) where some developer
> wants root on his development box, one of the major reasons they want it is
> *because* they know the admins are too busy running around admin'ing things to
> worry about the latest thing the developer needs changed on his box. They're
> trying to save you the trouble, so you can have the time to play with neat
> things.
I already said that most people are well-intentioned, but that does
nothing to protect you from the rest. It's them that we are concerned
about.
>
> Now, obviously, if the box they're using as a testbed is a shared,
> multiuser, production machine, opening up superuser access to them is a big
> step. You have to make sure they can be trusted, both politically and
> technically.
Which is completely and utterly impossible, no matter how well you THINK
you know someone.
> That is often (even usually) too big a risk given the rewards. In
> such a situation, the developer(s) really needs a testbed machine
> designated as such, so that when the box gets hosed, nobody was
> depending on it to be their file server.
>
> > By the way, we as sysadmins have a job to do too.
>
> You're right. It's supporting your company's operations. Don't
> ever forget you're not the reason the network is there.
It's precisely that consideration that drives this argument. It's not our
network, and it's not our data. But, WE are responsible for making sure
that it doesn't get stolen/trashed. THAT should never be forgotten.
-------------------------------------------------------------
As promised earlier, here are some good sources of security info:
Cliff Stoll's "The Cuckoo's Egg"
_Practical Unix Network Security_ O'Reilly
_Unix System Administrator's Handbook_ Nemeth, et. al.
_Maximum Linux Security (A hacker's Anonymous
guide to protecting your linux server
and workstation)_
_Maximum Security (a hacker's guide to Anonymous
protecting your internet site and
network)_
The last two may seem suspect, but they are extremely detailed and point
to excellent resources both on the net and in print. I have heard rumors
that they were both written by a rather notorious member of one of the
most well-known elite hacker groups. While I can't vouch for that, I will
say that I've seen and used some of the tools the book talks about (on my
own systems, OF COURSE!), and they scare me. It's no joke.
Happy reading...
--
PGP/GPG Public key at http://cerberus.ne.mediaone.net/~derek/pubkey.txt
------------------------------------------------------
Derek D. Martin | Unix/Linux Geek
[EMAIL PROTECTED] | [EMAIL PROTECTED]
------------------------------------------------------
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
