Kernel actualizado
- Inicie sesión o regístrese para enviar comentarios
Estaba leyendo una de las muchas vulverabilidades q salen a diario
https://unaaldia.hispasec.com/2018/11/denegacion-de-servicio-en-el-kernel-de-linux.html
Se han encontrado dos vulnerabilidades que podrían provocar una denegación de servicios en versiones del kernel de Linux 4.19.2 y anteriores.
Acabo de actualizar trisquel a 4.4.0-139 generic
Creo que hasta 4.19.2 va a pasar tiempo no? quiere decir q sere vulnerable por meses o años ? me ayudaria poner el kernel libre y poner la 4.20 de https://jxself.org/linux-libre/?
Como dice Jason Self, pone a disposición los nuevos kernels libres para quien los necesite por alguna razón.
He visto que en Ubuntu 18.04 el kernel es el 4.15 (Trisquel 9 se basará en este ubuntu).
La cuestión es que nuevos kernels pueden ser mas seguros pero también mas inestables, sobre todo el último. Supongo que es por eso que jxself da varias opciones según los intereses de cada uno.
Otra cuestión es si los kernels aguas abajo se benefician de la corrección de vulnerabilidades descubiertas...
Creo que lo que pasa es que en particular esta vulnerabilidad no es muy
preocupante.
En particular esa vulnerabilidad es preocupante sólo si: alguien tiene
acceso local a la computadora (o estás ejecutando código no-confiable), la
computadora es x86 y se está usando KVM (o sea que estás trabajando con
virtualización). Incluso en ese caso, lo que se puede conseguir es una
denegación de servicio, o sea que tu computadora podría dejar de andar y
tendrías que reiniciar.
O sea que este no es un problema urgente a solucionar en todas las
computadoras domésticas. En general, cuando un problema grave se encuentra,
el protocolo es distinto y lo que se hace es parchear (arreglar) muchas
versiones anteriores. O sea, que el parche se aplica sobre la versión 4.4.1
y se crea la versión 4.4.2, de forma que uno tiene los últimos arreglos de
seguridad, pero no la inestabilidad de las nuevas versiones.
Espero que esto ayude.
Suerte.
--- Eloy
El mié., 28 nov. 2018 a las 16:19, <name at domain> escribió:
> Como dice Jason Self, pone a disposición los nuevos kernels libres para
> quien los necesite por alguna razón.
> He visto que en Ubuntu 18.04 el kernel es el 4.15 (Trisquel 9 se basará
> en
> este ubuntu).
>
> La cuestión es que nuevos kernels pueden ser mas seguros pero también mas
> inestables, sobre todo el último. Supongo que es por eso que jxself da
> varias opciones según los intereses de cada uno.
> Otra cuestión es si los kernels aguas abajo se benefician de la
> corrección
> de vulnerabilidades descubiertas...
>
Muchas gracias . No conocia esa evolucion de los patches. No hay donde leer esas aclaraciones que has hecho? son muy interesantes , porque casi todos los dias salen falllos.
La verdad que no se dónde escuche sobre esto... me imagino que es algo que
leí
que hace debian o ubuntu con sus versiones estables, lo único que pude
encontrar
ahora buscando rápido, fue la documentación de Linux, en dónde se explica
como
es el proceso para solicitar que un parche que se aplicó en master, se
replique en
una versión anterior:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
En Debian, está esta respuesta en un faq:
https://www.debian.org/security/faq#oldversion
>* Q: Why are you fiddling with an old version of that package?*
> The most important guideline when making a new package that fixes a
security problem is to make as few changes as possible. Our users and
developers are relying on the exact behaviour of a release once it is made,
so any change we make can possibly break someone's system. This is
especially true in case of libraries: make sure you never change the
Application Program Interface (API) or Application Binary Interface (ABI),
no matter how small the change is.
> This means that moving to a new upstream version is not a good solution,
instead the relevant changes should be backported. Generally upstream
maintainers are willing to help if needed, if not the Debian security team
might be able to help.
> In some cases it is not possible to backport a security fix, for example
when large amounts of source code need to be modified or rewritten. If that
happens it might be necessary to move to a new upstream version, but this
has to be coordinated with the security team beforehand.
Que traducido de forma muy liberal dice: "Lo más importante al arreglar
fallos de seguridad es cambiar lo menos posible, ya que los usuarios
esperan estabilidad en los paquetes y cualquier cambio podría romper sus
sistemas. Por eso, actualizar a una nueva versión casi nunca es una opción
y los parches deben ser "backported" (o sea aplicados en versiones viejas).
Espero que esto sirva.
Saludos.
--- Eloy
El sáb., 1 dic. 2018 a las 9:09, <name at domain> escribió:
> Muchas gracias . No conocia esa evolucion de los patches. No hay donde
> leer
> esas aclaraciones que has hecho? son muy interesantes , porque casi todos
> los
> dias salen falllos.
>
- Inicie sesión o regístrese para enviar comentarios