On Mon, 3 Jul 2000, Eli Marmor wrote:

> Thank you all, Yosi, Tzafrir, Oleg, Ira, Chen, and Izar.
> 
> To say that now I'm less confused than before, will not be correct,
> but I'll try to use your generous responses to make decisions.
> 
> Anyway, some notes:
> 
> > "Mandrake also wins (hands down) the "easiest distribution to break
> > into remotely" and "easiest distribution to break into locally",
> > having finally released 8 fixes for very severe security bugs in 7.1
> 
> Oh, I read that quotation when it was published. It is a simple
> statistics-based interpretation, and not something fair to base
> judgement on. These 8 vulnerabilities were not Mandrake's (but
> shared for all the Linuxes), and most of them are not dangerous for
> people with the "paranoid" configuration mode. 

In this spesific case the statistics don't lie.

For instance - the userhelper problem (basically - userhelper didn't check
that pam modules are from inside /etc/pam.d , which gave a very easy local
root exploit) was discovered a while after mandrake 6.1 was out, but was
not officially fixed until after a couple of monthes mandrake 7.0 was out.
IIRC a corrected package was availble at mandrake-cooker, but anyway - it
was never anounced.

Another example - the one I mentioned in an earlier post about wu-ftpd .
The fix was availble at cooker since 26.6, but was only announced as an
official fix on 2.7 . And this is a searious remote root exploit.

Anyway - IIRC with all the recent security updates redhat responded much
faster. 

> 
> In addition, it is not easy to patch existing kernels with the
> secure-linux patches, because usually these kernels (especially RH
> and Mandrake) already contain many other patches, and are already
> different from the original Linus kernel. It is always better to
> get the kernel ready from the vendor, with all the patches already
> built-in, and the conflicts already resolved.

BTW: it is not that difficult to add oyur own patches to an existing
kernel configuration from an rpm:

Basically - download and install the source rpm of kernel
(kernel-*.src.rpm , not kernel-sources-*.noarch.rpm). Now edit
RPM/SPECS/kernel.spec :
add your own patches, or remove existing patches (edit the %prepare
section. Add additional %patch 'es if you want to add patches) and then
issue:

rpm -bp RPM/SPECS/kernel.spec 

and there you have a patched kernel source tree.

Or - in case you didn't get it right - re-edit kernel.spec and rerun rpm
-bp 

(note that I have never tried to do that)

> 
> > Mandrake position themselves as "more cutting edge" they don't wait for a
> > piece of software to be true, tried and tested before including it in a
> > distro, therefore it is possible to install a Mandrake that is less stable
> > than what you'd like your server to be.
> 
> It may look paradoxally, but keeping yourself with the "latest and
> greatest" versions, makes your distro safer against crackers, so -
> better as a server. Yes, sometimes it may be less stable ("new
> version, new bugs"...); But from my experience, all of the security
> holes are finally found and fixed, and most of the "successful"
> cracks were done when the OS was too old, or when the administrator
> forgot to install patches. 

This is why any good distro should make it easy to get all of its recent
security updates. I believe both Mandrake and RedHat's recent versions
include simple utilities to automate this (although MandrakeUpdate is
focused on a local X user).

And anyway:

wget -r ftp://distro.mirror/updates_dir

rpm -Fv *.rpm

should suffice on most cases (although it would be safer to check md5sums 
before installing)

>                             So if you start with the latest version,
> you have more chances to have less vulnerabilities in your OS. In
> any case, it doesn't save you from the need to install patches as
> soon as they are available, and the delay of Mandrake in providing
> the wu-ftpd patch looked very bad.
> 

-- 
Tzafrir Cohen
mailto:[EMAIL PROTECTED]
http://www.technion.ac.il/~tzafrir


=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to