Son una tradición y como tal deberían incluirse en las estadísticas de cada nueva versión de Linux. Al lado del número de cambios efectuados o desarrolladores que colaboran en su liberación, podría figurar un nuevo apartado con las rajadas de Torvalds en las listas del Kernel. Clasificadas en intensidad y donde se alcanzaría DEFCON 1 al romper el espacio de usuario.
El último en ganarse las reprimendas de Torvalds ha sido el desarrollador Kees Cook. El motivo: querer introducir en el ciclo de desarrollo de Linux 4.15, una medida de seguridad para proteger de forma preventiva al núcleo, de unas potenciales vulnerabilidades por desbordamiento de buffer.
Según Torvalds sin haber contrastado antes los efectos que podría tener. Para él, esto es peligroso porque «toca las cosas del núcleo» y no confía en que «la gente de seguridad haga cosas cuerdas».
La idea de Cook sería que en caso de detectarse un ataque al proceso usercopy del kernel (permite transmitir o recibir datos del núcleo al espacio de usuario), se mataría el mismo, evitando cualquier intento de escalada de privilegios, e impidiendo así la ejecución de código arbitrario.
Esta propuesta estaría inspirada en una función similar incluida en grsecurity (con los que Linus también tiene sus cosas).
El problema es que ese endurecimiento de la seguridad de usercopy, basado en el establecimiento de listas blancas que solo permitiría el uso de algunas áreas de almacenamiento de la memoria, podría tener consecuencias para el resto del núcleo, deteniendo aplicaciones o incluso provocando un kernel panic.
Si algo sabemos del desarrollo de Linux en estos 26 años es que es importante mantener la compatibilidad. Y que los cambios no deben ser radicales y deben ser introducidos en pequeñas dosis.
En este caso concreto se podrían utilizar simplemente advertencias de seguridad (esa es la opción que más le gusta a Linus), en vez de jugársela ya con la detención de procesos. Especialmente cuando no se trata de resolver una vulnerabilidad 0day o algo urgente, sino de introducir una nueva capa de protección (interesante, pero sin la que el kernel hasta ahora ha vivido sin problemas).
La propuesta de Cook de introducir un modo fallback en el kernel 4.15, hasta que estuviera suficiente testado el mismo, acabó de desatar la furia de Linus:
NO ES ACEPTABLE cuando la gente de seguridad establece nuevas reglas mágicas y luego crean kernel panic, cuando esas nuevas reglas son violadas.
Como una persona de seguridad, necesitas repetir este mantra:
«los problemas de seguridad son tan solo bugs»
[…]Mientras veas tus esfuerzos de endurecimiento principalmente como un «déjame matar la máquina o proceso en mal comportamiento», dejaré de tomar eses parches de mierda.
Hablo en serio sobre esto.
Alguna personas se han burlado de mi, cuando digo que la seguridad son principalmente «solo errores».
Esa gente de seguridad son j*didos idiotas.
Porque sinceramente, esa clase de persona que no acepta que esos problemas de seguridad son solo bugs, no quiero trabajar con ellos.
Si no ves tu trabajo como «depuración primero», simplemente no estoy interesado.
Evidentemente Torvalds no le tiene demasiado aprecio a lo que el llama el «circo de la seguridad». Y de seguro no le da especial preferencia sobre el conjunto del sistema. Así pues la propuesta de Kees Cook tendrá que esperar a Linux 4.16 y ser introducida en bocados más pequeños.
No es la única rabieta reciente de Torvalds con la gente de seguridad. Durante el desarrollo de Linux 4.14, hace menos un mes, también tuvo unas palabras bonitas para un desarrollador de la suite de seguridad apparmor, a cuenta del origen de una regresión, que no parecía dispuesto a admitir:
…Esta es la clase de basura que me hace pensar que tu opinión y tu código no puede ser confiable.
Si no estás dispuesto a admitir que tu commit 651e28c5537a («apparmor: add base infrastructure for socket mediation») provocó un regresión, entonces, sinceramente, no quiero recibir commits tuyos.
Es así de simple. Son las reglas del club del kernel.
La 1ª: no causarás regresiones rompiendo el espacio de usuario.
Imagen | John Dalton (CC-BY-SA-2.0)
Vía | The Register
«Esa gente de seguridad son j*didos idiotas.»
No, Torvalds. No son idiotas. Tampoco podemos hablar de solo bugs, es un error descomunal el llevar el «tema» seguridad a un Reductio ad absurdum.
Es increible que Linus no le ponga atención a la seguridad, por eso que ya hay malware, rootkits y otros que afecta a Linux. Me cambiaría a BSD pero ya tuve experiencia y no fue agradable. Incompatibilidad o no reconocimiento con el hardware, programas a compilar como gentoo, saber manejar dependencias (por lo menos gentoo te instala las dependencias) y seguramente algo se me queda en el tintero.
No sé que sistema BSD probaste tú, pero al menos en FreeBSD se resuelven dependencias automáticamente, tanto utilizando la herramienta pkg para instalar paquetes binarios, como utilizando los ports, precisamente ese es uno de los motivos por el que me gusta FreeBSD respecto a slack, que no quiero resolver dependencias manualmente ni tirar de gestores de paquetes externos.
probe openbsd, por el año 2008 y volví por el 2013. Freebsd lo descarté porque era muy hackeado por esos tiempos y descarté netbsd porque le interesaba la portabilidad en vez de la seguridad (y por eso que nació openbsd)
Ummm, en este tema es lo de siempre. Para él la seguridad es secundaria porque ya se encargan las empresas como google, intel y microsoft, (a las que él ha dado acceso al kernel) , de violarla.