Today, Bob Bell gleaned this insight:
> 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.
Bob, that's just not true. If a monitoring tool reported an attack as
coming from your machine, I'd be marching down to your office to take it
from you so I could inspect it, with company security behind me if
necessary (or possible).
It may well be true that YOU would never do such a thing, but the point is
the sysadmin team simply can't know that. Especially at a company as
large as Compaq, but no matter how large or small.
> 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.
Agreed.
>
> (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.
Yes.
> 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)
FTP, ssh, or similar; preferally ssh as it uses encryption, and does not
compromise your password if someone is sniffing your segment.
Don't think that's an issue? We had engineers at Arris who did this all
the time. We just interviewed a guy who told us he used a sniffer on his
network CONSTANTLY and watched the traffic go by when he was bored (bored
sysadmin? UNHEARD OF!).
And yes, this is more inconvenient than using NFS-mounted copies, but not
too much so.
> (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 limit where the software runs in a sensible fashion, and thereby
minimize the risk. Remember, we've said all along that it's up to
management to decide how secure they WANT to be... it may be that they
consider this an acceptable risk. But they need to work with the
sysadmins to understand any security implications. This almost never
happens.
> (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?
NIS is inherently insecure. There's not much you can do to fix it... Sun
tried for years. The security fix is don't use it.
> (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.
That's what code review is for. But these days most companies are too
preoccupied with getting the product out the door to bother with this.
That's why HP-UX has about a thousand patches per release.
> (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.
The real problem is that engineers aren't educated about the issues. I
think if you make them TRULY understand WHY your security policy is
implemented the way it is, they'll see the need for it, and be less likely
to grumble about the added inconvenience. You must reach a BALANCE
between security and convenience, and the sysadmins, management, AND all
of the engineers need to understand what risks exist, and the potential
consequences of leaving some risk in place.
Companies like the former DEC are sticky, because they've been around
since the beginning, when the Internet was a happy place. They didn't
need to be nearly so security concious. But things are a lot different
now, and the engineers need to be made to understand that.
> 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.
I'll take that as a compliment.. Thanks! And in general I'd say the same
about the engineers here. Linux seems to attract talent.
--
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
**********************************************************
