6.6. Comprobación de la autenticidad de un paquete

La seguridad es muy importante para los administradores de Falcot Corp. Por consiguiente, necesitan asegurar que sólo instalen paquetes con garantía de que provienen de Debian sin modificaciones en el camino. Un «cracker» podría intentar agregar código malicioso en un paquete que de otra forma sería legítimo. Si se instala tal paquete, éste podría hacer cualquier cosa para la que dicho «cracker» lo diseño, inclusive revelar contraseñas o información confidencial por ejemplo. Para evitar este riesgo, Debian provee un sello contra modificaciones para garantizar — al momento de instalación — que el paquete realmente proviene de su encargado oficial y no fue modificado por un tercero.

El sello funciona con una firma y una cadena de «hashes» criptográficos y se explica en detalle en apt-secure(8). A partir de Debian 10 Buster, el archivo InRelease, provisto por las réplicas Debian, es el firmado. También hay un archivo de la versión anterior llamado Release. Ambos contienen una lista de los archivos Packages (incluyendo sus formas comprimidas, Packages.gz y Packages.xz, así como las versiones incrementales), junto con sus «hashes» SHA256 lo que asegura que los archivos no fueron modificados. Estos archivos Packages contienen una lista de los paquetes Debian disponibles en la réplica junto con sus hashes lo que asegura, a su vez, que el contenido de los paquetes mismos tampoco fue modificado. La diferencia entre InRelease y Release es que el anterior está firmado criptográficamente en línea, mientras que el último proporciona una firma separada en la forma del archivo Release.gpg.

APT necesita un conjunto de claves públicas GnuPG para verificar las firmas disponibles en los archivos InRelease y Release.gpg disponibles en los espejos. Las obtiene de archivos en /etc/apt/trusted.gpg.d/ y del conjunto de claves /etc/apt/trusted.gpg (gestionado por la orden apt-key). Las claves oficiales de Debian son proporcionadas y mantenidas al día por el paquete debian-archive-keyring paquete que las pone en /etc/apt/trusted.gpg.d/:

# ls /etc/apt/trusted.gpg.d/
debian-archive-bullseye-automatic.gpg
debian-archive-bullseye-security-automatic.gpg
debian-archive-bullseye-stable.gpg
debian-archive-buster-automatic.gpg
debian-archive-buster-security-automatic.gpg
debian-archive-buster-stable.gpg
debian-archive-stretch-automatic.gpg
debian-archive-stretch-security-automatic.gpg
debian-archive-stretch-stable.gpg

EN LA PRÁCTICA Agregando llaves confiables

Cuando se agrega una fuente de paquetes de terceros al archivo sources.list, se necesita informar a APT que confíe en las llaves de autenticación GPG correspondientes (de lo contrario continuará quejándose de que no puede asegurar la autenticidad de los paquetes que provengan de dicho repositorio). El primer paso es, obviamente, obtener la llave pública. La mayoría de las veces encontrará dicha llave en un pequeño archivo de texto, que llamaremos key.asc en los siguientes ejemplos.

Para añadir una clave al conjunto de claves, el administrador puede ponerla en un archivo *.gpg en /etc/apt/trusted.gpg.d/ (Se desaconsejan los archivos *.asc pues pueden causar problemas). Esta aceptado desde Debian Stretch. Con versiones más antiguas, había que ejecutar apt-key add < key.asc, que ya se considera obsoleto.

Aunque esto es un comportamiento muy común, también crea un posible problema. APT no sabe qué clave pertenece a qué repositorio. Si una de las claves de APT coincide con la firma de un archivo, APT considera el archivo como autenticado. Una vez que se ha añadido una clave al depósito de claves de confianza, un atacante malicioso podría realmente proporcionar su propia "versión" de un espejo Debian firmado por la misma clave. Podría ser mejor poner la clave como archivo *.gpg en /usr/share/keyrings/ y usar el campo Signed-By en sources.list para repositorios de terceros como se muestra en el ejemplo siguiente.

Imagina, que el Falcot Corp. dirige su propio repositorio público y quieres usarlo. Lo han firmado y proporcionan una clave(ring) disponible públicamente también para descargar. Para restringir la clave del repositorio, simplemente puedes hacer esto:

$ sudo wget -O falcot-keyring.gpg -P /usr/share/keyrings https://packages.falcot.com/debian/repository.gpg

deb [ signed-by=/usr/share/keyrings/falcot-keyring.gpg ] https://packages.falcot.com/debian bullseye main

¡Tenga cuidado que al añadir y utilizar repositorios de terceros siempre plantea un riesgo de seguridad y estabilidad!

Una vez que las claves apropiadas se ecuentran en el conjunto, APT revisará las firmas antes de cualquier operación de riesgo para que las interfaces muestren una advertencia si pide instalar un paquete sobre el que no se puede verificar autenticidad.

Recuerde que los paquetes binarios generalmente no están firmados. La integridad de un paquete sólo se puede confirmar comprobando su suma de verificación contra una fuente de verificación de confianza (y posiblemente firmada).

CASO ESPECÍFICO eepositorios no firmados

Mientras que en general no se deben utilizar repositorios no firmados, algunos usuarios todavía podrían requerirlos, por ejemplo para proporcionar algunos paquetes construidos localmente. Se puede obligar a APT a aceptar tal repositorio anteponiendo la URL del repositorio usando allow-insecure=yes o trusted=yes. Lo demostraremos usando el ejemplo de Sección 15.3, “Creación de un repositorio de paquetes para APT”:

deb [ trusted=yes ] http://packages.falcot.com/ updates/
deb [ trusted=yes ] http://packages.falcot.com/ internal/