19 Actualizaciones de seguridad

De manera ocasional, vulnerabilidades importantes de seguridad se descubren en los paquetes de software y deben aplicarse parches. Las desarrolladoras de Guix tratan de seguir las vulnerabilidades conocidas y aplicar parches tan pronto como sea posible en la rama master de Guix (todavía no proporcionamos una rama “estable” que contenga únicamente actualizaciones de seguridad). La herramienta guix lint ayuda a las desarrolladoras a encontrar versiones vulnerables de paquetes de software en la distribución:

$ guix lint -c cve
gnu/packages/base.scm:652:2: glibc@2.21: probablemente vulnerable a CVE-2015-1781, CVE-2015-7547
gnu/packages/gcc.scm:334:2: gcc@4.9.3: probablemente vulnerable a CVE-2015-5276
gnu/packages/image.scm:312:2: openjpeg@2.1.0: probablemente vulnerable a CVE-2016-1923, CVE-2016-1924
…

See Invocación de guix lint, para más información.

Guix sigue una disciplina funcional de gestión de paquetes (see Introducción), lo que implica que, cuando se cambia un paquete, todos los paquetes que dependen de él deben ser reconstruidos. Esto puede ralentizar de manera significativa el despliegue de correcciones en paquetes básicos como libc o Bash, ya que básicamente la distribución al completo debe reconstruirse. El uso de binarios preconstruidos ayuda (see Sustituciones), pero el despliegue aún puede tomar más tiempo del deseado.

Para afrontar esto, Guix implementa injertos, un mecanismo que permite un rápido despliegue de actualizaciones críticas sin los costes asociados con una reconstrucción completa de la distribución. La idea es reconstruir únicamente el paquete que hace falta parchear, y entonces “injertarlo” en los paquetes explícitamente instalados por la usuaria y que previamente hacían referencia al paquete original. El coste de realizar un injerto es menor que una reconstrucción completa de la cadena de dependencias.

Por ejemplo, supongamos que es necesario incorporar una actualización de seguridad en Bash. Las desarrolladoras de Guix proporcionarán una definición de paquete para la versión “corregida” de Bash, digamos bash-fixed, de la manera habitual (see Definición de paquetes). Una vez hecho, la definición original del paquete es aumentada con un campo replacement que apunta al paquete que contiene la corrección del error:

(define bash
  (package
    (name "bash")
    ;; …
    (replacement bash-fixed)))

De ahí en adelante, cualquier paquete que dependa directa o indirectamente de Bash—como informa de ello guix gc --requisites (see Invocación de guix gc)—que se instale se “reescribe” automáticamente para hacer referencia a bash-fixed en vez de bash. Este proceso de injerto toma un tiempo proporcional al tamaño del paquete, normalmente menos de un minuto para un paquete “medio” en una máquina reciente. El injertado es recursivo: cuando una dependencia indirecta requiere un injerto, el injerto se “propagará” hasta el paquete que la usuaria esté instalando.

Actualmente, la longitud del nombre y la versión del injerto y aquella del paquete que reemplaza (bash-fixed y bash en el ejemplo previo) debe ser igual. Esta restricción viene principalmente del hecho de que el injertado funciona mediante la aplicación de parches en archivos, incluyendo archivos binarios, directamente. Otras restricciones pueden ser aplicables: por ejemplo, durante la adición de un injerto a un paquete que proporciona una biblioteca compartida, la biblioteca compartida y su reemplazo deben tener el mismo SONAME y deben ser compatibles a nivel binario.

La opción de línea de órdenes --no-grafts le permite anular voluntariamente el proceso de injerto (see --no-grafts). Por tanto, la orden:

guix build bash --no-grafts

devuelve el nombre de archivo del almacén de la versión original de Bash, mientras que:

guix build bash

devuelve el nombre de archivo del almacén de la versión “corregida”, reemplazo de Bash. Esto le permite distinguir entre las dos variantes de Bash.

Para verificar a qué Bash hace referencia su perfil al completo, puede ejecutar (see Invocación de guix gc):

guix gc -R $(readlink -f ~/.guix-profile) | grep bash

… y compare los nombres de archivo del almacén que obtendrá con los ejemplos previos. Del mismo modo, para una generación completa del sistema Guix:

guix gc -R $(guix system build my-config.scm) | grep bash

Por último, para comprobar qué versión de Bash están usando los procesos en ejecución, puede usar la orden lsof:

lsof | grep /gnu/store/.*bash