Con respecto a Open Wall me encontr� esto en el FAQ (no es que crea que
responda a todos los puntos de Alvaro pero me pareci� importante agregarlo y
no lo hice en su momento).
> -----Mensaje original-----
> De: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] nombre de
> Alvaro Figueroa
> Enviado el: Lunes, 24 de Marzo de 2003 06:06 a.m.
> Para: [EMAIL PROTECTED]
> Asunto: RE: distribuciones seguras
...
> Tengo cierto mal ride, y cierta reserva con los carajos
> por la nota de
> no intentar incluir el codigo en el kernel stock, sino
> en dejarselos
> como parches ahi medio juega de elite.[0] Si yo fuera
> ellos, yo hubiera
> hecho todo lo posible para que estos parches entren en
> 2.3 o en 2.5 en
> los momentos apropiados para la inclusion de parches.
>
De
http://www.openwall.com/linux/FAQ
cito lo que sigue:
"Q: Why don't they make it into the standard kernel?
A: This is not a trivial question to answer. First, some parts of older
versions of the patch (or equivalent, but different, fixes) are in fact
in the kernel now. This is the reason the patch for 2.0.36 was smaller
than it used to be in the 2.0.33 days. Now the patch for 2.2.13 is once
again smaller than its last 2.2.12 version. :-) So, security problems in
the kernel itself are typically getting fixed. It is, however, true that
the security "hardening" features of the patch are not getting in. One
of the reasons for this is that those features could result in a false
sense of security. Someone could then decide against fixing a hole on a
system they administer or in software they maintain just because of these
kernel features. If such things happen, the security is in fact relaxed,
not improved. The rlimit restrictions I have here are temporary hacks,
to be replaced with a real solution (beancounters), so I'm not trying to
get them into the kernel"
Ciro.
--
Desuscripci�n: escriba a [EMAIL PROTECTED], tema 'unsubscribe'
Problemas a: [EMAIL PROTECTED] http://www.linux.or.cr/listas
