La semana pasada el equipo de seguridad sufrió su ira una vez más aunque en esta ocasión no es por intentar introducir un parche defectuoso sino por hacer cambios en el kernel que provocan un comportamiento diferente al que espera Linus.
Hace unos días, Torvalds tubo un encontronazo con uno de los desarrolladores del subsistema de seguridad de Linux. Parece que el creador del sistema basado en Unix no está muy contento con la gente de seguridad del kernel y estos a su vez no parecen tomarle en serio.
Linus Torvalds apenas escribe código en la actualidad y su función consiste en coordinar los distintos equipos. Hay muchos que lo acusan de haber creado un ambiente de trabajo tóxico por la forma de expresarse y de dirigirse al resto de miembros.
El pasado viernes, Kees Cook (desarrollador de seguridad) propuso un parche para Linux 4.15 cuyo comportamiento consiste en cerrar procesos cuando se observan comportamiento erráticos. Añadió que le gustaría poder incluir su parche en la siguiente versión y no tener que esperar a la 4.16. Linus le respondió esto:
Sinceramente, estas cosas siempre esperan las últimas porque me dan miedo y no confío en ellas por lo que debo dedicarles tiempo.
Y cuando recibo más de 20 proposiciones de parches al día, no puedo dedicarles tiempo. Me dan miedo porque:
- tocan cosas del núcleo
- no confío en que la gente de seguridad haga las cosas con cabeza
- tienden a venir como si fuera un hecho consumado con un millón de reglas arbitrarias que no están ni terminadas.
[…]
Para terminar dice que probablemente este parche no entrará en esta versión por la falta de tiempo. Unas horas después, Cook responde:
[…] Por eso he introducido el modo ‘fallback’: tanto kvm como sctp (ipv6) no han sido notificados hasta que ha avanzado el proceso de desarrollo, me he sentido mucho menos satisfecho que si se hubiera probado lo suficiente. […] Con el modo ‘fallback’, las listas blancas generan una advertencia por lo que este parche sólo introduce controles estrictos […]. Estaría de acuerdo en que estaría bien coger al menos una parte de esto. Linus, ¿que te haría sentirte más a gusto?
La parte de no haber probado lo suficiente el parche, hace saltar el interruptor en la cabeza de Torvalds:
Sinceramente, este es el tipo de comportamiento de una «persona dedicada a la seguridad» que es completamente inaceptable […].
No es aceptable que la gente de seguridad establezca nuevas reglas mágicas y que luego se provoquen kernel panics cuando esas reglas se violan.
Eso es basura inmunda. Llevamos más de un cuarto de siglo sin esas reglas, de repente tu no vas y dices «oh, todo el mundo tiene que hacer eso y si no lo haces, matamos el kernel».
El hecho de que hayas «introducido el modo fallback» al final del desarrollo sólo demuestra LO INCREIBLEMENTE MAL que ha empezado el desarrollo.
En serio.
Como persona dedicada a la seguridad, tienes que repetir este mantra:
«los problemas de seguridad sólo sólo bugs».
Y tienes que interiorizarlo en vez de mofarte.
La parte importante sobre «sólo bugs» es que necesitas entender que los parches que introduces para cosas como ‘hardening’ son sobretodo para depurado.
No estoy interesado en matar procesos. El único proceso en el que estoy interesado es en el proceso de desarrollo donde encontramos bugs y los arreglamos.
Desde el momento en el tus esfuerzos por el ‘hardening’ son «déjame matar el proceso ante un mal comportamietno», dejo de coger esos parches de mierda.
Estoy muy en serio con esto.
Algunas personas de seguridad se han burlado de mi cuando he dicho que los problemas de seguridad son principalmente «tan sólo bugs».
Esas personas de seguridad son unos imbéciles.
Porque sinceramente, no quiero trabajar con el tipo de persona de seguridad que no acepta que los problemas de seguridad son principalmente tan sólo bugs. Si no ves tu trabajo como un «dupura primero», simplemente no estoy interesado.
Creo que el proyecto de ‘hardening’ tiene que mirarse al espejo.
Porque el principal objetico debería ser el «depurado». El principal objetivo debería ser «asegurémosnos de que el kernel publicado en un año es mejor que el publicado hoy».
Y el principal objetivo ahora parecer ser «matemos cosas provocadas por bugs». Eso está mal.
No estoy tan interesado en eso. Me hacer ir a «no, no voy a meter esa mierda, no es segura para mi y no es segura para nuestros usuarios».
Así que los esfuerzos del ‘hardening’ deberían empezar por «advirtamos sobre lo que parece peligroso y quizas en un año cuando hayamos advertido durante mucho tiempo y nos sintamos seguros de que de verdad hemos pillado todos los casos normales, entonces podemos empezar a hablar de medidas drásticas».
¿Ves la diferencia?
Deja esa idiotez de «primero mata y luego pregunta».
Porque está mal.
[…]
Y esto básicamente resume dos formas de llevar el desarrollo del kernel. Por una parte unos quieren poner en marcha medidas que evitaría comportamientos extraños por cualquier razón (inclusive fallos del programa) y otros consideran que es más razonable primero intentar solucionar los fallos que provocan esos comportamiento erráticos y luego ya veremos.