Son una tradición y como tal deberían incluirse en las estadísticas de cada nueva versión de Linux. Al lado de número de los 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 25 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