jdow wrote:
By contrast it is rare for a critical remote
vulnerability to be known for more than 3 days in Linux distributions
without having the update to fix it released.
Not as rare as all that. The folks involved, kernel, gnome, kde, OO, or
others, have to be informed. The person responsible then has to be woken
up from the grave or wherever else he's been hiding. A fix needs to be
generated AND validated against the software suite involved and the
items that depend on it. THEN the distros get it. In Red Hat's case with
Ingo and others on their staff, it's pretty quick.
Very quick indeed:
http://www.redhatmagazine.com/2007/04/18/risk-report-two-years-of-red-hat-enterprise-linux-4/
How quick is Debian?
How quick is "k12ltsp"?
K12ltsp isn't really a 'separate' distribution in the usual sense. It
is just a respun fedora or Centos (there are versions based on each)
with some other stuff added along with some scripted setup to make thin
client booting work out of the box. Updates still come through from the
base distribution so it's as fast as a stock fedora or centos would be.
And centos has been very timely in passing the updates along as soon as
the RHEL ones are available.
Another reason Linux appears more secure than windows is market share.
Windows is a far more profitable target to exploit. To start with they
are inevitably sloppier because they opt for user experience rather than
security and have fewer eyes on the code. When Linux is attacked with
the same level of intensity as Windows it gets cracked.
Sometimes, but once fixed it usually stays fixed. A lot of the
applications providing basic services in the *ix world have been around
several decades, incrementally improving over that time as problems are
identified and fixed.
This isn't as
easy. But it is done. Otherwise, why bother with RKHunter or chkrootkit?
Exploits like ssh password guessing are common and only partly related
to software flaws. Personally I think sshd should have always had its
own configurable login attempt throttle - but then I think the C
language should have fixed the executable, known-size stack frame
problem 20 years ago and file systems should have always provided a
non-executable tmp area by default... But these are things that would
only happen if the people distributing them were held responsible for
the problems they cause.
More secure is not absolutely secure. If I make more layers for the
critter to wriggle through I have a better chance of noticing it and
doing something about it. Hence, the root of this thread. I like the
features in iptables because I can tailor defense to make penetration
MUCH harder at the expense of only a slight impediment to access. That
is a really good thing in my book. That is why I passed the rules along
in the spirit by which I was clued in on a RedHat list some time ago.
It's better than a sharp stick in the eye, but fixing the actual
problems would be a lot better.
--
Les Mikesell
lesmikesell@xxxxxxxxx
