> (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...
In a test environment, this is great, so long as it is completely
segregated from the production environment.
> (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.
See last comment.. ;-P
> 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)
There are many 'secure' ways of doing this. One of many? ssh. Only way
to get into the test environment if you're in the production environment?
ssh. Provide it on a firewall that goes between the two networks.
> (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.
You shouldn't be selling something you don't run production yourself..
;-P Kill your marketting people..
> (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?
You shouldn't. The test environemtn should be a complete an independant
environment. Becouse it is lax on security, due to it's nature, it should
be segregated from the production network, and there needs to be a big fat
firewall in the way. And disallow root to ssh in on the production
machines.
> (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.
Sure enough. Could happen. Most jobs are inside jobs. But a locked down
environment and proper monitoring techniques employed by the Systems
Administrators can assist in detering this, if not catching it outright.
Now, if the intentional bug is in the buisness logic, your screwed. Bring
him to court.
> (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.
And I know individuals who would balk at working with Visual C++, VB,
Java, and Oracle. You're going to lose good people any way you look at it.
If they leave becouse you're anal, it's better then if they leave becouse:
A) Someone hacks into your web site.
B) Jumps to the test environment
C) Accesses lots of test data, gleaned from production databases..
D) Publishes them on a geocities web page, so 1 million CC numbers are
distributed.
E) No one uses you anymore, becouse you didn't handle security correctly..
F) People looking as the company begins to really hurt, and the anal stuff
happens *AFTER*
G) Hopefully, you can recover, but there's a chance you don't.
> 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.
And I see your points, as a software engineer. But if your paranoid all
the time, you're less likely to get a breakin.
**********************************************************
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
**********************************************************
