¿Cómo se garantiza la autenticidad de los paquetes de Debian?


8

¿Qué sistemas y procesos de seguridad existen para evitar que terceros malintencionados pirateen / comprometan la seguridad del código en los espejos de Debian, o para verificar que los paquetes que obtenemos son de hecho los que los encargados creen que son?

Respuestas:


14

Verificando paquetes

El contenido de los espejos se firma con claves PGP, directa o indirectamente. Comenzando en la "raíz" de una distribución Debian:

  • Release, firmado con una firma separada Release.gpg, contiene los hashes (MD5, SHA1, SHA256) de todos los índices de paquete y hash del instalador ( InReleaseahora combina los dos);
  • Los índices de paquetes ( por ejemplo , binary-amd64) contienen los hashes (MD5 y SHA256) de los paquetes.

Los hash y las firmas se verifican mediante herramientas como el apt-getuso de claves PGP almacenadas en el sistema (administradas por apt-key). Por lo tanto, siempre que el sistema receptor sea sólido, por defecto no se puede instalar ningún paquete desde los archivos de Debian si no ha sido firmado (indirectamente) por la clave PGP del archivo. Los intrusos en los espejos no podrían reemplazar los archivos binarios si tampoco tuvieran el control de la clave PGP correspondiente.

Controlando los espejos

Esto significa que comprometer el archivo no es suficiente para comprometer realmente los sistemas del usuario final; también necesitaría comprometer una clave PGP en la que esos sistemas ya confían. (Un corolario de esto es que agregar una clave a un sistema Debian no es algo que deba tomarse a la ligera). Eso responde a su primera pregunta hasta cierto punto, ya que la seguridad del archivo no importa tanto. Sin embargo, los sistemas críticos (donde ocurre la firma) son estrictamente monitoreados y supervisados, y muy pocas personas tienen acceso a ellos.

Expectativas del mantenedor

Asegurarse de que los paquetes sean "de hecho los que los encargados creen que son" es un poco más complicado. Este es el camino tomado por un paquete:

  • el paquete lo prepara un mantenedor y se firma con una clave en el conjunto de claves de Debian ( es decir, una clave que pertenece a un desarrollador de Debian que carga, o un mantenedor de Debian, cargada en el servidor de conjuntos de claves de Debian y fusionada por el equipo de mantenimiento de conjuntos de claves);
  • el paquete firmado se carga en el archivo, donde se verifica (entre otras cosas, las claves utilizadas deben estar en el llavero actual y no deben haber expirado, las firmas deben ser válidas, y si el paquete fue firmado por un DM, eso DM debe tener los permisos relevantes para el paquete);
  • los binarios cargados se envían al archivo final tal como están (estoy simplificando un poco aquí, pero ese es el efecto);
  • los archivos binarios faltantes son compilados por un buildd y firmados por la clave PGP del buildd, y se envían al archivo final (que sabe qué claves de buildd son válidas y verifica los archivos en contra de ellos);
  • todas estas actualizaciones eventualmente se envían a la red espejo, con las actualizaciones de índice apropiadas (que se firman como se describió anteriormente).

Si el responsable de mantenimiento carga los archivos binarios junto con la fuente del paquete, estos son los archivos que terminan sirviéndose (por el momento). Dado que cargar binarios ahora es opcional, es cada vez más común omitirlos, y eventualmente se eliminarán los binarios cargados. (Este siempre ha sido el caso en Ubuntu.) Si los otros binarios coinciden con las expectativas del mantenedor depende de la red construida; así que los edificios también son sistemas críticos, bajo estrecha supervisión y con poco acceso humano. Dado que todos los artefactos están firmados, siempre es posible verificar la integridad de los archivos: primero contra la clave del mantenedor, luego contra las claves de los buildds y finalmente contra la clave del archivo.

Como lo señaló plugwash , las firmas originales no están disponibles en los espejos, y cualquier DD puede cargar un binario faltante. Las firmas originales se pueden recuperar de los archivos debian-devel-changes .

En resumen , si bien el sistema actual no es perfecto, proporciona trazabilidad para todos los archivos que puede descargar de los espejos. Hay una serie de esfuerzos para mejorar la situación: compilaciones reproducibles (que permitirán la verificación independiente de la correspondencia de los binarios a la fuente publicada), eliminando los binarios proporcionados por el mantenedor ...


Admirablemente completo, pero también podría haberle dicho razonablemente al afiche que se fuera y leyera la documentación. :-)
Faheem Mitha

@FaheemMitha Dudé, pero ¿qué documentación? Hay wiki.debian.org/SecureApt, pero no cubre todo ... ¡Juntarlo todo es bastante complejo, a menos que haya otra documentación que no conozca!
Stephen Kitt

Entonces, ¿los SO de Debian que los usuarios ejecutan tienen claves PGP públicas pre-incrustadas, que están emparejadas con las claves privadas en los sistemas críticos (donde ocurre la firma) , y apt-getverifica los paquetes usando estas claves pre-incrustadas locales, porque confía en ellos?
the_velour_fog

1
@the_velour_fog sí, eso es (casi) correcto; Las claves públicas se envían en el debian-archive-keyringpaquete. apt-getverifica los Releasearchivos con esas claves y los paquetes con los hashes contenidos en los archivos Releasey Packages.
Stephen Kitt
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.