In a message dated: Wed, 04 Oct 2000 14:01:57 EDT
Tony Lambiris said:
>I never said RH couldn't work in a server environment. Also, not everyone is
>running in the same environment as you. Were your servers multi-user
>environments? Did you have amd or ftpd running on them?
On some servers yes, never had a problem (though I use autofs over amd).
>I also don't know how you can continue to use Red Hat full well knowing
>that with every release, there are going to be multiple bugs in the software.
Because the install is quick and painless, and most of the bugs never have to
do with software I plan on running on the server. Note also, that these are
internal machines behind a firewall, not directly connected to the 'net.
Of course I've run RH based firewalls with great success as well.
>Do you run Windows as well?
Not sure what you're referring to here. MS Windows clients? X Windows
on the server?
>And in case you missed it, I said the admin did a default install. If he
>had deleted packages he did not need, who knows if the crack ever would've
>happened.
No I didn't miss it. You also said:
>decided to install Red Hat. First of all, that was probably
>his first mistake.
and
>I just read on Slashdot that Red Hat 7.0 had over like 2,500
>documented bugs, or something outrageous like that.
Implying that, in your opinion, there is never any good reason to run RH as a
server. I was merely pointing out that there is nothing wrong with RH as a
server. Maybe it was more your intention to point out that rather than blame
the OS, it's far more productive to have an admin who knows what they're
doing. However, you did not state that.
>Point taken, but I didn't feel the need to go into the multiple factors
>affecting people submitting bug reports. Almost every environment is
>different. This is a matter of common sense.
But it's exacly those multiple factors which make your statements sound
ridiculous. You start out stating in effect, that there's no good reason
to run RH because there are something like 2500 bugs in the most recent
release. When in fact, 6.2 was one of the most stable releases they've had.
You insinuated by that statement that this admin made a mistake in installing
RH in the first place, then bring up the bug count in 7.0, as if to imply
that he/she installed 7.0. When in fact this was not the case at all,
since this incident happened long before 7.0 was released.
The bug count in 7.0 has absolutely no bearing on any previous release of
their distribution, so to bring this up was pointless. Especially since,
as I pointed out, the total bug count is that of "documented" bugs,
not "verified" as actually being a bug. So, it's theoretically possible
that the actual "verified" bug count could be 0 (though highly unlikely :)
>> Locked down and buggy are again, two different concepts. Just because a
>> certain distribution may or may not be buggy has nothing to do with
>> whether or not it can be hardened. RH is just like every other
>> distribution or Unix system for that matter, when it comes to be locked
>> down. You do exactly the same things to harden all Unix systems.
>
>Again, pointing out the obvious.
Well, it can't be too obvious if you were using the terms interchangably.
You insinuated by your comments that RH is buggy, and therefore can't be
locked down, when in fact the 2 have nothing to do with each other.
>Example: a new exploit comes out that writes a suid root shell to /tmp. First
>off, how many people create a seperate tmp partition (I do)? And how many
>people set the /tmp partition NOSUID in their fstab (I do)? Of course, if
>Red Hat did not decided to include that service (or at least turned on by
>default), they would've spared a lot of headaches.
I agree that RH does not necessarilly install services in a manner conducive
to good security practices, but that does not mean it's a bug, or that it
can not be locked down. This is what you implied, though evidently not what
you meant.
> Why spend a day or two locking down Red Hat, when you can install
> something like OpenBSD and have it secured in 2 minutes. It's inefficient.
Obviously there are many factors involved, and as you pointed out, every
site is different. For me, installing RH is quick. I know what I need to
install, how lock it down, and it takes very little time. OpenBSD, or any of
the BSDs for that matter are not a comfortable platform for me. I much prefer
the SysV-like environment which linux offers than the BSD environment.
Inefficiency is also dependant upon the person involved. It's far more
inefficient for me to learn a new environment, or re-learn an old environment
in the case of BSD, than it is to install RH and be done with it.
>> I love Debian, they just have a really crappy install tool).
>>
>I beg to differ, apt-get is by far the greatest and most powerful package
>installer.
Package installer and initial installation tool are 2 completely different
things. I love apt-get, but installing Debian on system takes far longer
and is much more complicated than installing RH on a system. Once installed,
I agree that Debian is a far superior and more stable environment than RH,
but for the initial installation, RH has the best installation tool.
>Well let's just put it this way... I have a few friends that attend Keene
>State college, and if the cracker was in fact an attendee at KSC, I would've
>been told, so the other obvious answer is that the cracker came from an
>outside source.
Or that you weren't told. I'm glad you have friends at Keene State, but
that doesn't mean much, other than they didn't know who it was, or they
didn't tell you.
Regardless, the reason for disallowing the system to be connected to the
internet was the fact that it was used to crack into another location,
not that it was in and of itself cracked.
>Yeah, I guess I really did it this time by misspelling a word. I should
>probably go through high school again as a punishiment for such a foolish
>thing to do in life.
It probably wouldn't hurt.
--
Seeya,
Paul
----
I'm in shape, my shape just happens to be pear!
If you're not having fun, you're not doing it right!
**********************************************************
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
**********************************************************
