Based on this (extended) conversion, here's what I here as far as
being applicable to my situation here. Perhaps the situation most
appealing to sysadmins that would still work would be:
(1) I need complete root access to my testing machines. I'm
mucking with a bunch of stuff, and I never know quite what I need to
muck with next. You could use sudo to log all my access, but there's
really no point, as admins wouldn't care what I did to my test machine
anyway. Also, part of my job involves installing the OS, so I'm going
to wind up setting the root password anyway. So I'll have the root
password to my test machines. However...
(2) I really don't need the password to my desktop machine. I could
use somewhat-restricted sudo access for this and probably still get
done what I need to.
(3) My desktop machine and my testing machines are on different
networks, or at least different subnets. My desktop machine is in a
production environment with other root-restricted machines running
released, proven software.
The drawbacks (or even problems) with this setup are:
(A) How do I handle information exchange between these networks? If
they're separated for security, how do I put my latest patches onto
the test machines, or telnet in and run commands? (You sysadmins may
have an answer, and I'm interested in the proper "secure" setup)
(B) While the production environment may be running different software
than the testing environment, it still is going to be somewhat recent.
We have what we call an IFT, or internal field test, where we install
our own unreleased but close-to-being-done software. I can't see this
going away, as how can we tell a customer how good our product is when
we aren't even using it ourselves yet? However, at this stage of the
game, there may still be some bugs in the product, perhaps (though
hopefully not) serious enough to cause security compromisses.
(C) Given that I have root on my own machine, the main thing we are
doing is keeping it separate from production machines. Why? It was
stated that anyone who knows what they are doing can extend root on
one machine to root on another in the same environment, exploiting
things like NIS. Well, if such a problem exists, shouldn't it be
fixed? Since we are writing all the software for a supposedly
high-end UNIX, shouldn't we be confident that these types of
situations shouldn't occur, and then rapidly fix them when they do?
(D) Keep in mind that a malicious employee is writing the software
that will eventually be used in the production environment. If he is
really malicious, the possibility exists for him to specifically
overlook some security flaw he created and wait for that software to
be installed in the production environment.
(E) Let's not overlook the people factor. I know you sysadmins would
probably disagree that this should be a considered factor, but I feel
obliged to at least point out the dissension (sp?) that may occur
among employees. A company may find it harder to attract quality
engineers when they balk at not having root access to their own
machines. If they are really good they'll recognize a properly
secured configuration, you say. Perhaps, but let's at least keep this
factor in mind.
Please note that I am *NOT* trying to antagonize any sysadmins. I
respect the quality of the sysadmins on this list, as they generally
appear to be higher knowledgeable, and I find this an interesting (and
classic) discussion.
--
Bob Bell Compaq Computer Corporation
Software Engineer 110 Spit Brook Rd - ZKO3-3/U14
TruCluster Group Nashua, NH 03062-2698
[EMAIL PROTECTED] 603-884-0595
**********************************************************
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
**********************************************************
