Re: Traducción del manual de seguridad al español: nota a traductores
infraestructure.sgml
--
Manuel Parrilla Sánchez
<!-- CVS revision of original english document "1.26" -->
<chapt>Infraestructura de Seguridad de Debian
<sect id="debian-sec-team">El Equipo de Seguridad de Debian
<p>Debian tiene un Equipo de Seguridad compuesto de cinco miembros y dos
secretarios que gestionan la seguridad de la versión <em>estable</em>. Gestionar
la seguridad significa seguir la pista a las vulnerabilidades de software que
aparecen (mirando en foros como Bugtraq, o vuln-dev) y determinar si afectan a
la versión <em>estable</em>.
<p>Además, el Equipo de Seguridad de Debian es el punto de contacto para
problemas que se coordinan por desarrolladores principales u organizaciones como
<url id="http://www.cert.org"; name="CERT">, que podrían afectar a múltiples
proveedores. Es decir, cuando los problemas no son específicos de Debian. Hay
dos puntos de contacto con el Equipo de Seguridad:
<list>
<item><url id="mailto:team@security.debian.org";
name="team@security.debian.org"> leído únicamente por los miembros del equipo de
seguridad.
<item><url id="mailto:security@debian.org"; name="security@debian.org"> leído por
todos los desarrolladores de Debian (incluido el equipo de seguridad). Los
mensajes enviados a esta lista no se publican en Internet (no es una lista de
correo pública).
</list>
<p>La información delicada debería enviarse a la primera dirección y, en algunos
casos, debería cifrarse con la llave de Contacto de Seguridad de Debian (ID
363CCD95).
<p>Una vez que el Equipo de Seguridad ha recibido un posible problema,
investigará si la distribución <em>estable</em> se ve afectada y si es así, se
hará el correspondiente arreglo en el código fuente base. Este arreglo, en
ocasiones, incluye adaptar el parche que se realizó para una versión de
desarrollo (que normalmente corresponde a una versión posterior a la distribuida
por Debian). Tras probar el arreglo, se preparan y publican nuevos paquetes en
el sitio <url id="security.debian.org"> de forma que puedan recuperarse con
<prgn>apt</prgn> (véase <ref id="security-update">). Al mismo tiempo, se publica
en la web un <em>Aviso de Seguridad de Debian</em> (DSA) y se envía a las
listas de correo públicas incluyendo <url
id="http://lists.debian.org/debian-security-announce";
name="debian-security-announce"> y Bugtraq.
<p>En <ref id="debian-sec-team-faq"> pueden encontrarse algunas otras preguntas
de uso frecuente sobre el Equipo de Seguridad de Debian.
<sect id="dsa">Avisos de Seguridad de Debian
<p>Los Avisos de Seguridad de Debian (DSAs) se hacen siempre que se descubre una
vulnerabilidad de seguridad que afecte a paquetes de Debian. Estos avisos de
seguridad, firmados por uno de los miembros del Equipo de Seguridad, incluyen
información de las versiones afectadas, así como la localización de las
actualizaciones y sus sumas MD5. Esta información es:
<list>
<item>número de versión para el arreglo.
<item>tipo de problema.
<item>si puede explotarse localmente o de forma remota.
<item>pequeña descripción del paquete.
<item>descripción del problema.
<item>descripción de la vulnerabilidad.
<item>descripción del arreglo.
</list>
<p>Los DSAs se publican en <url id="http://www.debian.org/";
name="Debian's mainserver frontpage"> y en <url
id="http://www.debian.org/security/"; name="Debian security pages">.
Normalmente esto no sucede hasta que no se reconstruye el sitio web (cada cuatro
horas) por lo que puede no aparecer inmediatamente. El canal preferente es la
lista de correo debian-security-announce.
<p>Los usuarios interesados pueden, sin embargo (y esto se hace en algunos
portales relacionados con Debian), utilizar el canal RDF para descargar
automáticamente los DSAs a su escritorio. Algunas aplicaciones, como
<prgn>Evolution</prgn> (un cliente de correo y asistente de información
personal) y <prgn>Multiticker</prgn> (una miniaplicción de GNOME), pueden
utilizarse para recuperar automáticamente los avisos. El canal de RDF está
disponible en <url id="http://www.debian.org/security/dsa.rdf";>.
<p>Los DSAs publicados en la web podrían actualizarse tras ser enviados a las
listas de correo públicas. Una actualización común añade referencias cruzadas a
las bases de datos de vulnerabilidades de seguridad. Además, las
traducciones<footnote>Las traducciones están disponibles hasta en diez lenguas
diferentes.</footnote> de DSAs no se envían a las listas de correo de seguridad
pero se incluyen directamente en el sitio web.
<sect1 id="crossreference">Referencias cruzadas de vulnerabilidades
<p>Debian proporciona una completa <url
id="http://www.debian.org/security/crossreferences";
name="tabla de referencias cruzadas"> que incluye todas las referencias
disponibles para todos los avisos de seguridad publicados desde 1998. Esta tabla
se proporciona para complementar el <url
id="http://cve.mitre.org/cve/refs/refmap/source-DEBIAN.html";
name="mapa de referencia disponible en CVE">.
<P>Notará que esta tabla proporciona referencias a las bases de datos de
seguridad como <url id="http://www.securityfocus.com/bid";
name="Bugtraq">,
<url id="http://www.cert.org/advisories/"; name="Avisos de seguridad de CERT/CC">
y <url id="http://www.kb.cert.org/vuls"; name="Base de datos de notas de
vulnerabilidades de US-CERT"> así como nombres de CVE (véase más abajo). Estas
referencias se proporcionan para su utilización, pero únicamente las referencias
de CVE se revisan e incluyen periódicamente. Esta característica se añadió al
sitio web en junio de 2002.
<p>Una de las ventajas de añadir referencias cruzadas a estas bases de datos de
vulnerabilidades es que:
<list>
<item>hace más sencillo a los usuarios de Debian ver y seguir qué avisos de
seguridad general (publicados) ya han sido resueltos por Debian.
<item>los administradores del sistema pueden aprender más sobre las
vulnerabilidades y su impacto, mediante el seguimiento de las referencias
cruzadas.
<item>esta información puede utilizarse para comprobar los resultados de la
búsqueda de vulnerabilidades, que incluyen referencias a CVE para eliminar falsos
positivos (véase <ref id="vulnasses-false-positive">).
</list>
</sect1>
<sect1 id="cve-compatible">Compatibilidad de CVE
<P>Los Avisos de Seguridad de Debian fueron <url
id="http://www.debian.org/security/CVE-certificate.jpg"; name="declarados
CVE-Compatibles"><footnote>El <url
id="http://cve.mitre.org/compatible/phase2/SPI_Debian.html";
name="cuestionario de habilidad"> completo está disponible en CVE</footnote> el
24 de febrero de 2004.
<p> Los desarrolladores de Debian entienden la necesidad de proporcionar
información precisa y actualizada del estado de la seguridad de la distribución
Debian, permitiendo a los usuarios controlar los riesgos asociados a las nuevas
vulnerabilidades de seguridad. CVE nos habilita para proporcionar referencias
estandarizadas que permitan a los usuarios desarrollar un <url
id="http://www.cve.mitre.org/compatible/enterprise.html";
name="proceso de control de la seguridad habilitado por CVE">.
<p>El proyecto <url id="http://cve.mitre.org"; name="Common Vulnerabilities and
Exposures (CVE)"> es mantenido por la Corporación MITRE y proporciona una lista
de nombres estandarizados para vulnerabilidades y exposiciones de seguridad.
<P>Debian cree que es extremadamente importante proporcinar a los usuarios
información adicional relacionada con temas de seguridad que afectan a la
distribución de Debian. La inclusión de los nombres de CVE en avisos de
seguridad ayuda a los usuarios a asociar vulnerabilidades genéricas con
actualizaciones de Debian específicas, lo que reduce el tiempo empleado por sus
usuarios en el manejo de las vulnerabilidades. Además, facilita la gestión de la
seguridad en un entorno en el que herramientas de seguridad de CVE habilitadas
-tales como sistemas de detección de intrusos en ordenadores o redes, o
herramientas de evaluación de vulnerabilidades- son utilizadas sin tenerse en
cuenta que se trate de una distribución de Debian o no.
<p>Debian comenzó a añadir nombres de CVE a los DSAs en junio de 2002, y ahora
proporciona nombres de CVE para todos los DSAs desde septiembre de 1998, tras un
proceso de revisión que comenzó en agosto de 2002. Todos los avisos de seguridad
pueden recuperarse del sitio web de Debian, y los anuncios relacionados con
nuevas vulnerabilidades incluyen nombres de CVE si están disponibles en el
momento de su emisión. Los avisos de seguridad asociados con un nombre de CVE
dado pueden buscarse directamente en el <url id="http://search.debian.org/";
name="motor de búsqueda">.
<p> Los usuarios que quieran buscar un nombre de CVE particular pueden utilizar
el motor de búsqueda de web disponible en debian.org, para recuperar avisos de
seguridad disponibles (en inglés y traducido a otras lenguas) asociados con
nombres de CVE. Se puede hacer una búsqueda para un nombre específico (como
advisory <url
id="http://search.debian.org/?q=advisory+%22CAN-2002-0001%22&ps=50&o=1&m=all";
name="CAN-2002-0001">) o para nombre parciales (como todos los candidatos de
2002 incluidos en búsquedas de avisos para <url
id="http://search.debian.org/?q=advisory+%22CAN-2002%22&ps=50&o=1&m=all";
name="CAN-2002">). Observe que necesita introducir la palabra «advisory» junto
con el nombre de CVE para recuperar únicamente los avisos de seguridad.
<p>En algunos casos podría no encontrar un nombre de CVE en concreto entre los
avisos de seguridad publicados, por ejemplo debido a que:
<list>
<item> No hay productos de Debian afectados por esa vulnerabilidad.
<item> No hay todavía un aviso que cubra esa vulnerabilidad (el tema de
seguridad podría haberse comunicado como un <url
id="http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=security";
name="error de seguridad"> pero no se ha subido ni probado ninguna
corrección).
<item> Se publicó un aviso antes de que un nombre de CVE se asignara a una
vulnerabilidad dada (busque una actualización en el sitio web).
</list>
</sect1>
</sect>
<sect>Infraestructura de Seguridad en Debian
<p>Puesto que Debian está soportado en gran número de arquitecturas, los
adiministradores algunas veces se preguntan si una arquitectura determinada
tardará más en recibir las actualizaciones de seguridad que otras. En realidad,
salvo en casos excepcionales, las actualizaciones están disponibles a la vez
para todas las arquitecturas.
<p>Aunque hace un tiempo las tareas de construcción de las actualizaciones de
seguridad se realizaban a mano, actualmente no es así (según describe Anthony
Towns en
<url
id="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00002.html";
name="un correo"> enviado a la lista debian-devel-announce mailing list con
fecha de 8 de junio de 2002).
<p>Las firmas de los paquetes subidos con un parche apropiado por el equipo de
seguridad (a <url id="security.debian.org:/org/security.debian.org/queue/unchecked"> o
<url id="ftp://security.debian.org/pub/SecurityUploadQueue";>) son comprobadas
durante los quince minutos siguientes a partir del momento de la subida. Una
vez hecho, se añaden a la lista de los autoconstructores (los cuales ya no se
ejecutan una vez al día). De este modo, los paquetes pueden construirse
automáticamente para <em>todas</em> las arquitecturas, entre treinta minutos y
una hora después de ser subidos. Sin embargo, las actualizaciones de seguridad
son un poco diferentes a las subidas normales enviadas por los responsables de
paquetes, puesto que, en algunos casos, antes de publicarse se necesita esperar
hasta que puedan probarse, se escriba un aviso, o se necesita esperar una semana
o más para evitar la publicidad del defecto, hasta que todos los proveedores
hayan tenido oportunidad de corregirla.
<p>Así, el archivo de las subidas de seguridad funciona de la siguiente forma
(llamada <em>"Accepted-Autobuilding"</em>):
<list>
<item>Alguien encuentra un problema de seguridad.
<item>Alguien corrige el problema, y lo sube al buzón de security.debian.org
(este <em>alguien</em> normalmente es un miembro del Equipo de Seguridad,
aunque también puede ser un responsable del paquete con una corrección
apropiada, que se ha puesto en contacto previamente con el Equipo de
Seguridad). El Registro de Cambios incluye una indicación de la
distribución de destino: <em>testing-security</em> o
<em>stable-security</em>.
<item>Lo subido se comprueba y procesa por un sistema Debian, se pone como «en
cola/aceptado», y se notifica a los constructores. El equipo de seguridad y
(de forma indirecta) los constructores pueden acceder a los archivos.
<item>Los constructores con habilitación de seguridad recogen el paquete fuente
(tienen prioridad sobre los constructores normales), lo construyen, y
envían los registros al equipo de seguridad.
<item>El equipo de seguridad contesta a los registros, y los paquetes recién
construidos se suben a «en cola/sin probar», donde son procesados por un
sistema Debian, y puestos como «en cola/aceptado».
<item>Cuando el equipo de seguridad encuentra aceptable el paquete fuente (es
decir, se ha construido correctamente para todas las arquitecturas
aplicables y se ha corregido el agujero de seguridad sin introducir nuevos
problemas) ejecutan un «script», el cual:
<list>
<item>Instala el paquete en el archivo de seguridad.
<item>Actualiza los archivos <file>Packages</file>, <file>Sources</file> y
<file>Release</file> de security.debian.org en la forma habitual
(<prgn>dpkg-scanpackages</prgn>, <prgn>dpkg-scansources</prgn>, ...).
<item>Configura un aviso patrón que el equipo de seguridad puede rematar.
<item>Envía (opcionalmente) los paquetes para las actualizaciones apropiadas,
para que puedan incluirse en el archivo real tan pronto como sea posible.
</list>
</list>
<p>Este procedimiento, hecho anteriormente a mano, se probó y pasó durante la
etapa de estabilización de Debian 3.0 woody (July 2002). Gracias a esta
infraestructura, el Equipo de Seguridad pudo tener paquetes actualizados listos
para Apache y OpenSSH para todas las arquitecturas soportadas (casi treinta) en
menos de un día.
<sect1>Guía del desarrollador de actualizaciones de seguridad
<p>Este mensaje de correo fue enviado por Wichert Akkerman a la <url
id="http://lists.debian.org/debian-devel-announce/2002/debian-devel-announce-200206/msg00004.html";
name="lista de correo Debian-devel-announce"> para describir el comportamiento
de los desarrolladores de Debian en el manejo de problemas de seguridad en sus
paquetes. Se publica aquí para el beneficio de los desarrolladores y para que
los usuarios entiendan mejor cómo se maneja la seguridad en Debian.
<p>ARRÉGLEME: Por favor, observe que las referencias actualizadas para esta
información están en <url
id="http://www.debian.org/doc/manuals/developers-reference/ch-pkgs#s-bug-security";
name="Referencia del Desarrollador de Debian">, esta sección se eliminará
próximamente.
<sect2>Coordinar con el equipo de seguridad
<p>Si un desarrollador se entera de un problema de seguridad, bien en su paquete
o en cualquier otro, debería ponerse en contacto con el equipo de seguridad (en
team@security.debian.org). Ellos llevan la cuenta de los problemas de seguridad
pendientes y pueden ayudar a los responsables con los problemas de seguridad o
corregirlos ellos mismos. También son responsables de enviar avisos de seguridad
y mantener security.debian.org.
<p>Por favor, tenga en cuenta que los avisos de seguridad sólo se hacen para las
distribuciones publicadas, no para la de pruebas, inestable (N. del T.: testing
y unstable respectivamente)(véase <ref id="sec-unstable">) o distribuciones
antiguas (véase <ref id="sec-older">).
<sect2>Tener conocimiento de los problemas de seguridad
<p>Hay unas cuantas formas en las que un desarrollador puede enterarse de un
problema de seguridad:
<list>
<item>se entera en un foro público (lista de correo, sitio web, et.).
<item>alguien presenta un informe de fallo (debería usarse la etiqueta
<em>Security</em>, o ser añadida por el desarrollador).
<item>alguien le informa a través de su correo privado.
</list>
<p>En los dos primeros casos la información es pública y es importante
corregirlo tan pronto como sea posible. En el último caso sin embargo, la
información podría no ser pública. En este caso hay una cuantas opciones
posibles para tratar el problema:
<list>
<item>si es un problema trivial (como archivos temporales inseguros) no hay
necesidad de mantener el problema en secreto y se podría hacer una corrección
y publicarla.
<item>si el problema es grave (vulnerabilidad de forma remota, posibilidad de
adquirir privilegios de superusuario) es preferible compartir la información
con otros proveedores y coordinar una publicación. El equipo de seguridad
mantiene contactos con varias organizaciones e individuos y puede ocuparse de
eso.
</list>
<p>En todos los casos, si la persona que informa del problema pide que no se
desvele la información debería ser respetada, con la excepción obvia de informar
al equipo de seguridad (el desarrollador debería asegurarse de decirle al equipo
de seguridad que no se desvele la información).
<p>Por favor, tenga en cuenta que si el secreto es necesario, el desarrollador
puede también no subir una corrección a «unstable» (o a cualquier otro sitio),
puesto que la información del registro de cambios para «unstable» es información
pública.
<p>Hay dos razones para publicar información incluso aunque se solicite/requiera
el secreto: el problema se conoce desde hace mucho tiempo, o la información se
hace pública.
<sect2>Construir un paquete
<p>La directriz más importante a la hora de construir un nuevo paquete que
corrija un problema de seguridad, es hacer los mínimos cambios posibles. La
gente confía en el exacto comportamiento de una publicación una vez que ésta ha
tenido lugar, por ello cualquier cambio que se haga puede llevar a que algunos
sistemas dejen de funcionar. Esto es especialmente cierto para las librerías: el
desarrollador debe asegurarse de que nunca cambia el API o el ABI, no importa lo
pequeño que sea el cambio.
<p>Esto significa que moverse a una nueva versión principal no es una buena
solución, en lugar de eso, se deberían adaptar los cambios
relevantes. Generalmente los desarrolladores originales están dispuestos a
ayudar si es necesario, si no, el Equipo de Seguridad de Debian también podría
ayudar.
<p>En algunos casos no es posible adaptar una corrección de seguridad, por
ejemplo cuando se necesita modificar o reescribir una gran cantidad de código
fuente. Si esto ocurre podría ser necesario moverse a una nueva versión
principal, pero siempre debería coordinarse de antemano con el equipo de
seguridad.
<p>Hay otro aspecto importante relacionado con esto: los desarrolladores tienen
siempre que probar sus cambios. Si hay una vulnerabilidad el desarrollador
debería probar si ésta tenía éxito en el paquete anterior a la modificación y
falla en el paquete corregido. El desarrollador debería probar también el uso
normal, ya que a veces la corrección de algún aspecto de seguridad puede afectar
de forma sutil al normal funcionamiento.
<p>Por último, unas cuantas consideraciones técnicas que los desarrolladores
deberían mantener en mente:
<list>
<item> Asegurarse de apuntar a la distribución correcta en
debian/changelog. Para la versión estable ésta es «stable-security» y para la de
pruebas «testing-security». No apuntar a <codename>-proposed-updates.
<item>Asegurarse de que el número de versión es el correcto. Tiene que ser mayor
que el del paquete actual, pero más bajo que las versiones de paquete de las
distribuciones posteriores. Para la de pruebas esto significa que tiene que
haber una versión más alta en «inestable». Si no hay ninguna todavía (porque «de
pruebas» e «inestable» tienen la misma versión, por ejemplo) subir primero a
«inestable» una nueva versión.
<item>No suba únicamente las fuentes si su paquete tiene algunos paquetes
binarios. La infraestructura de «build» no los construirá.
<item>Cuando compile un paquete, asegúrese de compilarlo en un sistema limpio
que sólo tenga paquetes instalados desde la distribución que esté construyendo.
Si no dispone de tal sistema, puede probar con una máquina de debian.org (vea
http://db.debian.org/machines.cgi) o configure un «chroot» (los paquetes
<package>pbuilder</package> y <package>debootstrap</package> pueden ser útiles
en ese caso).
</list>
<sect2>Subir correcciones de seguridad
<p>Después de que el desarrollador haya creado y probado el nuevo paquete,
necesitará subirlo para que pueda instalarse en los archivos. Para las subidas
de seguridad el lugar utilizado es
ftp://security.debian.org/pub/SecurityUploadQueue/ .
<p>Una vez aceptada una subida a la cola de seguridad, el paquete se
reconstruirá de forma automática para todas las arquitecturas y se almacenará
para ser verificado por el equipo de seguridad.
<p> Únicamente el equipo de seguridad tiene acceso a las subidas que se
encuentran a la espera de aceptación o verificación. Esto es necesario puesto
que podría haber correcciones para problemas de seguridad que todavía no se
hayan desvelado.
<p>Si un miembro del equipo de seguridad acepta un paquete, éste se instalará en
security.debian.org, así como el apropiado <codename>-proposed-updates
en ftp-master o el archivo non-US.
<sect2>Los avisos de seguridad
<p>Los avisos de seguridad son escritos y enviados por el equipo de
seguridad. Sin embargo, a ellos no les importa si el responsable de un paquete
les proporciona (parte de) el texto. En <ref id="dsa"> se describe qué
información debe incluirse en un aviso de seguridad.
<sect id="deb-pack-sign">Firma de paquetes Debian
<p>Esta sección podría también titularse «cómo actualizar de forma segura su
sistema Debian GNU/Linux» y merece su propia sección porque es una parte
importante de la Infraestructura de Seguridad. La firma de paquetes es un tema
importante puesto que evita la falsificación de los paquetes distribuidos en las
réplicas y de las descargas con ataques «man-in-the-middle» (mitm) (N. del T.:
ataque en el que el intruso adquiere la capacidad de leer, insertar y modificar
a voluntad, los mensajes entre dos partes sin que ninguna de ellas se dé cuenta
de que el enlace entre ellos ha sido violado). La actualización automática del
software es una característica importante, pero también es importante eliminar
las amenazas de seguridad que podrían ayudar a la distribución de troyanos y a
comprometer al sistema durante las actualizaciones<footnote>
<p>Algunos sistemas operativos ya han estado plagados con problemas de
actualizaciones automáticas tales como la <url name="Vulnerabilidad de la
Actualización de Software Mac OS X"
id="http://www.cunap.com/~hardingr/projects/osx/exploit.html";>.
<p>ARRÉGLAME: probablemente las vulnerabilidades de Internet Explorer en el
manejo de cadenas de certificados tenga su impacto en las actualizaciones de
seguridad de Microsoft Windows.
</footnote>.
<p>A partir de febrero de 2006 Debian no proporciona paquetes firmados para la
distribución y las versiones <em>woody</em> o <em>sarge</em> (3.0 o 3.1) no
integran esta característica. Hay una solución para paquetes firmados que será,
con un poco de suerte, proporcionada en la próxima versión (de nombre
<em>etch</em>). Esta nueva característica está disponible en apt 0.6
(actualmente disponible en la distribución <em>inestable</em>, véase <ref
id="apt-0.6">).
<p>Este tema se describe mejor en el
<url id="http://www.cryptnet.net/fdp/crypto/strong_distro.html"; name="Strong
Distribution HOWTO"> por V. Alex Brennen.
<sect1>El esquema propuesto para la comprobación de firmas de paquetes
<p>El esquema actual para la comprobación de firmas de paquetes utilizando
<prgn>apt</prgn> es:
<list>
<item>El archivo <file>Release</file> incluye la suma MD5 de
<file>Packages.gz</file> (que contiene las sumas MD5 de paquetes) y estará
firmada. La firma procede de una fuente de confianza.
<item>Este archivo <file>Release</file> firmado se descarga con «apt-get update»
y se almacena junto a <file>Packages.gz</file>.
<item>Cuando se va a instalar un paquete, primero se descarga y luego se genera
la suma MD5.
<item>Se comprueba el archivo <file>Release</file> firmado (firma ok) y se
extrae de él la suma MD5 para el archivo <file>Packages.gz</file>, se genera la
suma de control (N. del T.: «checksum») de <file>Packages.gz</file> y (si es ok)
se extrae la suma MD5 del paquete descargado.
<item>Si la suma MD5 del paquete descargado es la misma que la que se incluye en
el archivo <file>Packages.gz</file>, el paquete es instalado, en caso contrario
se alertará al administrador y se mantendrá el paquete en la caché (hasta que el
administrador decida si instalarlo o no). Si el paquete no está en
<file>Packages.gz</file> y el administrador ha configurado el sistema para que
únicamente se instalen paquetes comprobados, el paquete no se instalará tampoco.
</list>
<p>Siguiendo la cadena de sumas MD5, <prgn>apt</prgn> es capaz de verificar que
un paquete tiene su origen en una distribución específica. Esto es menos
flexible que firmar cada paquete uno por uno, pero también puede combinarse con
ese esquema (véase más abajo).
<p>Actualmente, este esquema está <url
id="http://lists.debian.org/debian-devel/2003/debian-devel-200312/msg01986.html
" name="completamente implementado"> en apt 0.6, el cual está actualmente
disponible en las distribuciones «de pruebas» e «inestable». Para más información
vea <ref id="apt-0.6">. Los paquetes que proveen de una interfaz a apt necesitan
modificaciones para adaptarse a esta nueva característica; este es el caso de
<prgn>aptitude</prgn> que ha sido <url
id="http://lists.debian.org/debian-devel/2005/03/msg02641.html";
name="modificado"> para adaptarlo a este esquema. Las interfaces que se sabe que
funcionan bien actualmente con esta característica incluyen a <prgn>aptitude</prgn> y
<prgn>synaptic</prgn>.
<p>La firma de paquetes se ha discutido en Debian durante bastante tiempo. Para
más información puede leer:
<url id="http://www.debian.org/News/weekly/2001/8/";> y
<url id="http://www.debian.org/News/weekly/2000/11/";>.
<sect1 id="apt-0.6">apt seguro
<p>La versión apt 0.6, disponible en las versiones «de pruebas» (actualmente
<em>etch</em>) e «inestable», incluye <em>apt-secure</em>
(también conocido como <em>secure apt</em>) que es una herramienta que permitirá
al administrador del sistema probar la integridad de los paquetes descargados
por medio del esquema anterior. Esta versión incluye la herramienta
<prgn>apt-key</prgn> para añadir nuevas claves al archivo de claves de apt, que
de forma predeterminada incluye únicamente la clave del paquete Debian.
<p>Estos cambios están basados en el parche para <prgn>apt</prgn> (disponible en
<url id="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203741"; name="Bug
#203741">) que proporciona esta implementación.
<p>«Apt seguro» trabaja comprobando la distribución por medio del archivo
<file>Release</file>, como se discute en <ref id="check-releases">. Típicamente,
este proceso será transparente al administrador, aunque necesitará intervenir
todos los años<footnote>Mientras no se desarrolle un mecanismo
automático.</footnote> para añadir la nueva clave del archivo cuando ésta es
modificada. Para más información sobre los pasos a llevar a cabo por un
administrador eche un vistazo a <ref id="secure-apt-add-key">.
<p>Esta característica está aún en desarrollo, si usted cree encontrar errores
en ella, por favor, asegúrese primero de estar utilizando la última versión
(puesto que este paquete podría cambiar bastante antes de su publicación final)
y, si está ejecutando la última versión, enviar un error contra el paquete
<package>apt</package>.
<sect1 id="check-releases">Control de las publicaciones de la distribución
<p>Esta sección describe cómo trabajan los mecanismos de control de las
publicaciones de la distribución; la escribió Joey Hess y también está
disponible en el <url id="http://wiki.debian.org/SecureApt"; name="Wiki de
Debian">.
<sect2>Conceptos básicos
<p>Aquí se describen una serie de conceptos que necesitarán para entender el
resto de la sección.
<p>Una suma de control (N. del T.: checksum) es un método que toma un archivo
y lo reduce a un número razonablemente pequeño que identifica de forma única el
contenido del archivo. Esto es más difícil de lo que podría parecer, y el tipo
de suma de control más utilizado, las suma MD5, está en vías de desaparición.
<p>El cifrado de clave pública está basado en un par de claves, una clave
pública y otra privada. La clave pública se le da a todo el mundo; la clave
privada se mantiene en secreto. Cualquiera que posea la clave pública puede
cifrar un mensaje de forma que únicamente pueda ser leída por alguien que posea
la clave privada. También es posible utilizar una clave privada para firmar un
archivo, no para cifrarlo. Si se utiliza una clave privada para firmar un
archivo, entonces cualquiera que tenga una clave pública puede comprobar que el
archivo ha sido firmado por esa clave. Nadie puede efectuar esa firma sin tener
la clave privada.
<p>Estas claves son números bastante largos (de 1024 a 2048 dígitos o más), y
para que resulte más sencillo trabajar con ellas tienen un id de clave, que es
un número más corto, de 8 o 16 dígitos, que puede utilizarse para referirse a
ellas.
<p><prgn>gpg</prgn> es la herramienta utilizada en «apt seguro» para firmar
archivos o para realizar las comprobaciones de éstas.
<p><prgn>apt-key</prgn> es un programa utilizado para gestionar un registro de
claves de gpg para «apt seguro». El registro de claves se guarda en el archivo
<file>/etc/apt/trusted.gpg</file> (no confundirlo con el relacionado pero no muy
interesante <file>/etc/apt/trustdb.gpg</file>). <prgn>apt-key</prgn> puede
utilizarse para mostrar las claves del registro, y para añadir o eliminar
claves.
<sect2>Sumas de control del archivo <file>Release</file>
<p>Los repositorios de Debian contienen un archivo <file>Release</file> que
cambia cada vez que se actualiza alguno de los paquetes del repositorio. Entre
otras cosas, el archivo <file>Release</file> contiene algunas sumas MD5 de otros
archivos. A continuación se muestra un extracto de un archivo
<file>Release</file> de ejemplo:
<example>
MD5Sum:
6b05b392f792ba5a436d590c129de21f 3453 Packages
1356479a23edda7a69f24eb8d6f4a14b 1131 Packages.gz
2a5167881adc9ad1a8864f281b1eb959 1715 Sources
88de3533bf6e054d1799f8e49b6aed8b 658 Sources.gz
</example>
<p>Los archivos <file>Release</file> incluyen también sumas SHA-1, que serán
útiles una vez que desaparezcan completamente las sumas MD5, sin embargo apt no
las usa todavía.
<p>Ahora si miramos dentro de un archivo <file>Packages</file>, encontraremos
más sumas de control MD5, una por cada paquete listado en él. Por ejemplo:
<example>
Package: uqm
Priority: optional
...
Filename: unstable/uqm_0.4.0-1_i386.deb
Size: 580558
MD5sum: 864ec6157c1eea88acfef44d0f34d219
</example>
<p>Estas dos sumas de control pueden utilizarse para verificar que se ha
descargado una copia correcta del archivo <file>Packages</file>, con una md5sum
que case con la que figura en el archivo <file>Release</file>. Y cuando se
descarga un paquete individual, también se comprueba su md5sum contra el
contenido del archivo <file>Packages</file>. Si apt falla en alguno de estos
pasos, abortará.
<p>Nada de esto es nuevo en «apt seguro», pero proporciona los
fundamentos. Observe que de momento hay un archivo que apt no tiene forma de
comprobar: el archivo Release. Con «apt seguro» se trata de hacer que apt verifique
el archivo <file>Release</file> antes de hacer nada más con él, y evitar así
problemas de seguridad, de forma que sea posible verificar toda la cadena de
confianza desde el paquete que se va a instalar hasta el proveedor de éste.
<sect2>Verificación del archivo <file>Release</file>
<p>Para verificar el archivo <file>Release</file>, se ha añadido una firma gpg
para el archivo <file>Release</file>. Ésta se ha puesto en un archivo de nombre
<file>Release.gpg</file> que va junto al archivo <file>Release</file>. Parece
algo como esto <footnote>Técnicamente hablando, esto es una firma gpg separada
de blindaje ASCII.</footnote>, aunque en realidad únicamente gpg mira
normalmente su contenido:
<example>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQBCqKO1nukh8wJbxY8RAsfHAJ9hu8oGNRAl2MSmP5+z2RZb6FJ8kACfWvEx
UBGPVc7jbHHsg78EhMBlV/U=
=x6og
-----END PGP SIGNATURE-----
</example>
<sect2>Comprobación de <file>Release.gpg</file> por <prgn>apt</prgn>
<p>«Apt seguro» descarga siempre los archivos <file>Release.gpg</file> cuando
descarga los archivos <file>Release</file>, y si no puede descargar
<file>Release.gpg</file>, o si la firma es mala, se quejará, y tomará nota de
que los archivos <file>Packages</file> a los que apunta el archivo
<file>Release</file>, y todos los paquetes listado allí, no son de una fuente de
confianza. Lo que aparecerá durante un <prgn>apt-get update</prgn> es:
<example>
W: GPG error: http://ftp.us.debian.org testing Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F
</example>
<p>Observe que la segunda mitad del número largo es el identificador de la clave
que apt desconoce, en este caso ésta es 2D230C5F.
<p>Si usted ignora este aviso e intenta instalar el paquete más tarde, apt le
avisará de nuevo:
<example>
WARNING: The following packages cannot be authenticated!
libglib-perl libgtk2-perl
Install these packages without verification [y/N]?
</example>
<p>Si contesta aquí con una Y, no tendrá forma de saber si el archivo que está
obteniendo es el que quiere instalar, o es algo completamente diferente que
alguien que pueda interceptar la comunicación con el servidor<footnote>O ha
envenenado su DNS, o ha suplantado el servidor, o ha sustituido el archivo en el
repositorio que usted esté usando, etc.</footnote> ha preparado para usted,
conteniendo una desagradable sorpresa.
<p>Observe que puede deshabilitar estas comprobaciones ejecutando apt con la
opción --allow-unauthenticated.
<p>También conviene notar que las versiones más recientes del instalador de
Debian utilizan el mismo mecanismo del archivo <file>Release</file> firmado
durante la instalación del sistema base de Debian mediante debootstrap, antes de
que apt esté disponible, e incluso antes de que el instalador utilice este
sistema para verificar sus propias partes descargadas de la red. Además, Debian
no firma actualmente los archivos <file>Release</file> en sus CDs; pero apt
puede configurarse para que siempre confíe en los paquetes de los CDs por lo que
esto no es un grave problema.
<sect2>Cómo decirle a apt en qué confiar
<p>Entonces la seguridad del sistema completo depende de lo que hay en un
archivo <file>Release.gpg</file>, el cual firma un archivo <file>Release</file>,
y de que <prgn>apt</prgn> cofirme esta firma utilizando gpg. Para comprobar la
firma, tiene que conocer la clave pública de la persona que firmó el
archivo. Estas claves se mantienen en el archivo de claves del propio apt
(<file>/etc/apt/trusted.gpg</file>), y mediante el control de las claves es como
se llega al apt seguro.
<p>De manera predeterminada, los sistemas Debian vienen preconfigurados con la
clave de los repositorios de Debian en el archivo de claves.
<example>
# apt-key list
/etc/apt/trusted.gpg
--------------------
pub 1024D/4F368D5D 2005-01-31 [expires: 2006-01-31]
uid Debian Archive Automatic Signing Key (2005) >ftpmaster&debi
an.org<
</example>
<p>Aquí 4F368D5D es el identificador de la clave, y tenga en cuenta que esta
clave es válida únicamente durante un año. Debian alterna estas claves como una
última línea de defensa contra algún tipo de brecha abierta en la seguridad de una
clave.
<p>Eso hará que apt confíe en los repositorios oficiales de Debian, pero si
añade algún otro repositorio para apt en el archivo
<file>/etc/apt/sources.list</file>, tendrá que darle también su clave si quiere
que apt confíe en él. Una vez que tenga la clave y la haya verificado, es algo
tan sencillo como ejecutar <prgn>apt-key add file</prgn> para añadirla. Obtener
la clave y verificarla son los aspectos más delicados.
<sect2>Encontrar la clave para un repositorio
<p>De momento no existe una localización estándar donde encontrar la clave para
un repositorio de apt dado. En ocasiones se pondrá la clave en la página web del
repositorio o como un archivo en el propio repositorio, pero no es un estándar
real, por lo que podría tener que buscarla.
<p>La clave de firma de los repositorios de Debian está disponible en <url
id="http://ftp-master.debian.org/ziyi_key_2006.asc";> (sustituya 2006 por el año
actual).<footnote>«ziyi» es aparentemente el nombre de una <url
id="http://en.wikipedia.org/wiki/Zhang_Ziyi"; name="actriz china">.
</footnote>
<p>El propio <prgn>gpg</prgn> tiene una forma estándar de distribuir claves,
utilizando un servidor de claves desde el que gpg puede descargar una clave y
añadirla a sus archivos de claves. Por ejemplo:
<example>
$ gpg --keyserver pgpkeys.mit.edu --recv-key 2D230C5F
gpg: requesting key 2D230C5F from hkp server pgpkeys.mit.edu
gpg: key 2D230C5F: public key "Debian Archive Automatic Signing Key (2006) <ftpm
aster@debian.org>" imported
gpg: Total number processed: 1
gpg: imported: 1
</example>
<p>Usted puede exportar esa clave desde su propio archivo de claves y dirigirlo
a <prgn>apt-key</prgn>:
<example>
$ gpg -a --export 2D230C5F | sudo apt-key add -
gpg: no ultimately trusted keys found
OK
</example>
<p>El aviso "gpg: no ultimately trusted keys found" significa que gpg no se ha
configurado para asumir en última instancia una clave específica. La
configuración de «trust» es parte de OpenPGPs Web-of-Trust, lo que no es aquí de
aplicación. Por tanto este aviso no tiene importancia. En configuraciones
típicas la propia clave del usuario es asumida finalmente.
<sect2 id="secure-apt-add-key">Añadir una clave de forma segura
<p>Al añadir una clave al archivo de claves de apt, le está diciendo a apt que
confía en todo lo que esté firmado con esa clave, y le permite estar seguro de
que apt no instalará nada que no esté firmado por la persona que posee la clave
privada. Pero si es lo suficientemente paranoico, puede ver que esto únicamente
hace subir las cosas un nivel y ahora,en vez de tener que preocuparse por un
paquete, o por la validez de un archivo <file>Release</file>, puede preocuparse
acerca de si usted ha obtenido la clave correcta. Está en el archivo <url
id="http://ftp-master.debian.org/ziyi_key_2006.asc";> mencionado anteriormente
realmente la clave de firma de los repositorios de Debian, o ha sido modificado
(o este documento miente).
<p>Es bueno ser paranoico en seguridad, pero verificar las cosas en ese caso es
más duro. <prgn>gpg</prgn> tiene el concepto de una cadena de confianza que
puede comenzar en alguien de quién se esté seguro, el que firme la clave de
alguien, el que firma alguna otra clave, etc., hasta que llega a la clave del
repositorio. Si es lo suficiente paranoico, querrá comprobar que su clave del
repositorio está firmada con una clave en la que puede confiar, con una cadena
de confianza que vuelva a alguien que conozca personalmente. Si quiere hacer
esto, visite una conferencia de Debian o quizá un LUG local para obtener una
firma de clave.
<footnote>No todas las claves de repositorio de apt están firmadas en absoluto
por otra clave. Quizá la persona que configure el repositorio no tenga otra
clave, o quizá no se sienta cómodo firmando tal clave a seguir con su clave
principal. Para obtener información sobre cómo configurar una clave para un
repositorio véase <ref id="check-non-debian-releases">.
</footnote>
<p> Si no puede permitirse este nivel de paranoia, haga lo mismo que considera
apropiado cuando añade una fuente para apt y una nueva clave. Puede que quiera
enviar un mensaje de correo electrónico a la persona que proporciona la clave y
verificarla, o quizá esté dispuesto a correr el riesgo de descargarla y asumir
que obtuvo la auténtica. Lo importante es que el problema se ha reducido a «en
qué claves de repositorios confiar», y con ello apt seguro le permite ser tan
cuidadoso y seguro como desee.
<sect2>Verificar la integridad de la clave
<p>Puede verificar la huella digital (N. del T.: «fingerprint») así como las
firmas de la clave. La recuperación de la huella digital puede hacerse para
múltiples fuentes, puede comprobarse <url
id="http://debiansystem.info/readers/changes/547-ziyi-key-2006"; name="El Libro
del Sistema Debian">, hablar con los desarrolladores de Debian por IRC, leer la
lista de correo en la que se anuncien los cambios de clave o cualquier otro
medio adicional para verificar la huella digital. Por ejemplo puede hacer esto:
<example>
$ GET http://ftp-master.debian.org/ziyi_key_2006.asc | gpg --import
gpg: key 2D230C5F: public key "Debian Archive Automatic Signing Key (2006)
<ftpmaster&debian.org>" imported
gpg: Total number processed: 1
gpg: imported: 1
$ gpg --check-sigs --fingerprint 2D230C5F
pub 1024D/2D230C5F 2006-01-03 [expires: 2007-02-07]
Key fingerprint = 0847 50FC 01A6 D388 A643 D869 0109 0831 2D23 0C5F
uid Debian Archive Automatic Signing Key (2006) <ftpmaster@debian.org>
sig!3 2D230C5F 2006-01-03 Debian Archive Automatic Signing Key
(2006) <ftpmaster@debian.org>
sig! 2A4E3EAA 2006-01-03 Anthony Towns <aj@azure.humbug.org.au>
sig! 4F368D5D 2006-01-03 Debian Archive Automatic Signing Key
(2005) <ftpmaster@debian.org>
sig! 29982E5A 2006-01-04 Steve Langasek <vorlon@dodds.net>
sig! FD6645AB 2006-01-04 Ryan Murray <rmurray@cyberhqz.com>
sig! AB2A91F5 2006-01-04 James Troup <james@nocrew.org>
</example>
y luego <url
id="http://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s-deb-pack-sign";
name="compruebe la ruta de confianza"> desde su clave (o una clave en la que
confíe) hasta al menos una de las claves utilizadas para firmar la clave del
repositorio. Si es lo suficientemente paranoico, le dirá a apt que confíe en la
clave únicamente si encuentra una ruta aceptable:
<example>
$ gpg --export -a 2D230C5F | sudo apt-key add -
Ok
</example>
<p>Observe que la clave está firmada con la anterior clave del repositorio, por
eso teoricamente puede agregar su confianza anterior.
<sect2>Rotación anual de la clave de repositorios Debian
<p>Como se mencionó anteriormente, la clave de la firma de los repositorios
Debian se cambia todos los años, en enero. Debido a que apt seguro lleva poco
tiempo, no tenemos mucha experiencia en el cambio de la clave y hay aún algunos
puntos sin pulir.
<p>En enero de 2006, apareció una nueva clave para el 2006 y comenzó a firmarse
con ella el archivo <file>Release</file>, pero para evitar estropear sistemas
que tuvieran la clave antigua de 2005, el archivo <file>Release</file> se firmó
también con ésta. La intención era que apt aceptará una firma o la otra
dependiendo de la clave que tuviera, pero apt no funcionó como se esperaba y
rechazaba confiar en el archivo a menos que tuviera ambas claves y pudiera
comprobar ambas firmas. Esto se corrigió en la versión 0.6.43.1 de apt. Había
algo de confusión sobre cómo se distribuía la clave a los usuarios que ya
tuvieran sistemas utilizando apt seguro; inicialmente se subió a la web sin
anunciarse y sin una forma real de verificarse y se forzó a los usuarios a
descargarla manualmente.
<p>Basado en esta experiencia, a continuación se describe como podrían funcionar
las cosas en 2007:
<list>
<item>A principios de enero se creará una nueva clave para el 2007. Quizá esta
vez con un anuncio y una cadena de confianza bien definida.
<item>El archivo <file>Release</file> se firmará con su clave, aunque también se
firmará todavía con la clave de 2006. apt y otras herramientas aceptarán
ambas firmas.
<item>Se habrá instalado de antemano un nuevo paquete,
<package>debian-server-keyring</package>, en todos los sistemas. Se realizará
una actualización para incluir la clave de 2007. Cuando los usuarios actualicen
a la nueva versión, usarán <prgn>apt-key</prgn> para actualizar sus archivos de
claves, eliminando la clave de 2006 y añadiendo la clave de 2007.
<item>La clave de 2006 expira el 31 de enero de 2007.
</list>
Todavía hay incertidumbre sobre lo que le ocurrirá a los que no realicen ninguna
actualización en enero, y cómo tratará esta actualización la gente que utiliza
la versión estable, cuando «apt seguro» esté disponible para ellos.
<sect2>Problemas conocidos en la comprobación de la versión
<p>Un problema no tan obvio es que si su reloj está muy desactualizado, «apt
seguro» no funcionará. Si está puesto en una fecha pasada, como 1999, apt
fallará con un mensaje no muy claro, tal como éste:
<example>
W: GPG error: http://archive.progeny.com sid Release: Unknown error executing gpg
</example>
<p>Aunque la lista de <prgn>apt-key</prgn> hará el problema evidente:
<example>
gpg: key 2D230C5F was created 192324901 seconds in the future (time warp or clock problem)
gpg: key 2D230C5F was created 192324901 seconds in the future (time warp or clock problem)
pub 1024D/2D230C5F 2006-01-03
uid Debian Archive Automatic Signing Key (2006) <ftpmaster@debian.org>
</example>
<p>Si está puesto en una fecha futura muy lejana, tratará las claves como si
hubieran expirado.
<p>Otro problema que puede encontrar si utiliza las versiones «de pruebas» o
«inestable» es que si no ha ejecutado <prgn>apt-get update</prgn> últimamente e
instala un paquete mediante <prgn>apt-get install</prgn>, apt podría quejarse de
que no puede autentificarlo (¿por qué hace esto?). <prgn>apt-get update</prgn>
evita esto.
<sect2 id="manual-check-releases">Comprobación manual de versiones de la
distribución
<p>En caso de que quiera añadir ahora comprobaciones adicionales de seguridad y
no quiera o no pueda ejecutar la última versión de apt<footnote>Bien porque esté
usando la versión estable o una versión anterior, o porque no quiera utilizar la
última versión de apt, aunque agradeceríamos realmente que la
probara.</footnote> puede utilizar el «script» siguiente, proporcionado por
Anthony Towns. Este «script» puede hacer algunas nuevas comprobaciones de
seguridad de forma automática , para permitir al usuario estar seguro de que el
software que ha descargado coincide con el software de la distribución de
Debian. Esto impide que los desarrolladores de Debian accedan a algún sistema
sin la responsabilidad de haber subido el software al repositorio principal, o a
las réplicas, pero no nos protegerá del repositorio o de las réplicas que
suministren copias desactualizadas o inestables con problemas de seguridad
conocidos.
<p>Este código de muestra, renombrado como <prgn>apt-check-sigs</prgn>, debería
utilizarse de la siguiente forma:
<example>
# apt-get update
# apt-check-sigs
(...results...)
# apt-get dist-upgrade
</example>
<p>Primero necesita:
<list>
<item>obtener las claves que utiliza el software del repositorio para firmar los
archivos <file>Release</file>, <url
id="http://ftp-master.debian.org/ziyi_key_2006.asc";> y añadirlas a to
<file>~/.gnupg/trustedkeys.gpg</file> (que es lo que utiliza <prgn>gpgv</prgn>
de forma predeterminada).
<example>
gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2006.asc
</example>
<item>eliminar cualquier linea de <file>/etc/apt/sources.list</file> que no
utilice la estructura «dists» normal, o cambiar el archivo de órdenes para que
trabaje con ellas.
<item>estar preparado para ignorar el hecho de que las actualizaciones de
seguridad de Debian no hayan firmado los archivos <file>Release</file>, y que
los archivos <file>Sources</file> no tengan las sumas de control (checksums)
apropiadas en el archivo <file>Release</file> (todavía).
<item>estar preparado para comprobar que las fuentes apropiadas estén firmadas
con las claves adecuadas.
</list>
<p>Este es el código de ejemplo para <prgn>apt-check-sigs</prgn>, la última
versión puede obtenerse en <url
id="http://people.debian.org/~ajt/apt-check-sigs";>. Este código es actualmente
una versión beta, para obtener más información léa <url
id="http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00421.html";>.
<example>
#!/bin/bash
# Copyright (c) 2001 Anthony Towns <ajt@debian.org>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
rm -rf /tmp/apt-release-check
mkdir /tmp/apt-release-check || exit 1
cd /tmp/apt-release-check
>OK
>MISSING
>NOCHECK
>BAD
arch=`dpkg --print-installation-architecture`
am_root () {
[ `id -u` -eq 0 ]
}
get_md5sumsize () {
cat "$1" | awk '/^MD5Sum:/,/^SHA1:/' |
MYARG="$2" perl -ne '@f = split /\s+/; if ($f[3] eq $ENV{"MYARG"}) {
print "$f[1] $f[2]\n"; exit(0); }'
}
checkit () {
local FILE="$1"
local LOOKUP="$2"
Y="`get_md5sumsize Release "$LOOKUP"`"
Y="`echo "$Y" | sed 's/^ *//;s/ */ /g'`"
if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
if [ "$Y" = "" ]; then
# No file, but not needed anyway
echo "OK"
return
fi
echo "$FILE" >>MISSING
echo "MISSING $Y"
return
fi
if [ "$Y" = "" ]; then
echo "$FILE" >>NOCHECK
echo "NOCHECK"
return
fi
X="`md5sum < /var/lib/apt/lists/$FILE | cut -d\ -f1` `wc -c < /var/lib
/apt/lists/$FILE`"
X="`echo "$X" | sed 's/^ *//;s/ */ /g'`"
if [ "$X" != "$Y" ]; then
echo "$FILE" >>BAD
echo "BAD"
return
fi
echo "$FILE" >>OK
echo "OK"
}
echo
echo "Checking sources in /etc/apt/sources.list:"
echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
echo
(echo "You should take care to ensure that the distributions you're downloading
"
echo "are the ones you think you are downloading, and that they are as up to"
echo "date as you would expect (testing and unstable should be no more than"
echo "two or three days out of date, stable-updates no more than a few weeks"
echo "or a month)."
) | fmt
echo
cat /etc/apt/sources.list |
sed 's/^ *//' | grep '^[^#]' |
while read ty url dist comps; do
if [ "${url%%:*}" = "http" -o "${url%%:*}" = "ftp" ]; then
baseurl="${url#*://}"
else
continue
fi
echo "Source: ${ty} ${url} ${dist} ${comps}"
rm -f Release Release.gpg
lynx -reload -dump "${url}/dists/${dist}/Release" >/dev/null 2>&1
wget -q -O Release "${url}/dists/${dist}/Release"
if ! grep -q '^' Release; then
echo " * NO TOP-LEVEL Release FILE"
>Release
else
origline=`sed -n 's/^Origin: *//p' Release | head -1`
lablline=`sed -n 's/^Label: *//p' Release | head -1`
suitline=`sed -n 's/^Suite: *//p' Release | head -1`
codeline=`sed -n 's/^Codename: *//p' Release | head -1`
dateline=`grep "^Date:" Release | head -1`
dscrline=`grep "^Description:" Release | head -1`
echo " o Origin: $origline/$lablline"
echo " o Suite: $suitline/$codeline"
echo " o $dateline"
echo " o $dscrline"
if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then
echo " * WARNING: asked for $dist, got $suitline/$codeline"
fi
lynx -reload -dump "${url}/dists/${dist}/Release.gpg" >/dev/null 2>&1
wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg"
gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] //p" | (okay=0; err=""; while read gpgcode rest; do
if [ "$gpgcode" = "GOODSIG" ]; then
if [ "$err" != "" ]; then
echo " * Signed by ${err# } key: ${rest#* }"
else
echo " o Signed by: ${rest#* }"
okay=1
fi
err=""
elif [ "$gpgcode" = "BADSIG" ]; then
echo " * BAD SIGNATURE BY: ${rest#* }"
err=""
elif [ "$gpgcode" = "ERRSIG" ]; then
echo " * COULDN'T CHECK SIGNATURE BY KEYID: ${rest %% *}"
err=""
elif [ "$gpgcode" = "SIGREVOKED" ]; then
err="$err REVOKED"
elif [ "$gpgcode" = "SIGEXPIRED" ]; then
err="$err EXPIRED"
fi
done
if [ "$okay" != 1 ]; then
echo " * NO VALID SIGNATURE"
>Release
fi)
fi
okaycomps=""
for comp in $comps; do
if [ "$ty" = "deb" ]; then
X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Release" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Release")
Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Packages" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Packages")
if [ "$X $Y" = "OK OK" ]; then
okaycomps="$okaycomps $comp"
else
echo " * PROBLEMS WITH $comp ($X, $Y)"
fi
elif [ "$ty" = "deb-src" ]; then
X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Release" | sed 's,//*,_,g'`" "${comp}/source/Release")
Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Sources" | sed 's,//*,_,g'`" "${comp}/source/Sources")
if [ "$X $Y" = "OK OK" ]; then
okaycomps="$okaycomps $comp"
else
echo " * PROBLEMS WITH component $comp ($X, $Y)"
fi
fi
done
[ "$okaycomps" = "" ] || echo " o Okay:$okaycomps"
echo
done
echo "Results"
echo "~~~~~~~"
echo
allokay=true
cd /tmp/apt-release-check
diff <(cat BAD MISSING NOCHECK OK | sort) <(cd /var/lib/apt/lists && find . -type f -maxdepth 1 | sed 's,^\./,,g' | grep '_' | sort) | sed -n 's/^> //p' >UNVALIDATED
cd /tmp/apt-release-check
if grep -q ^ UNVALIDATED; then
allokay=false
(echo "The following files in /var/lib/apt/lists have not been validated."
echo "This could turn out to be a harmless indication that this script"
echo "is buggy or out of date, or it could let trojaned packages get onto"
echo "your system."
) | fmt
echo
sed 's/^/ /' < UNVALIDATED
echo
fi
if grep -q ^ BAD; then
allokay=false
(echo "The contents of the following files in /var/lib/apt/lists does not"
echo "match what was expected. This may mean these sources are out of date,"
echo "that the archive is having problems, or that someone is actively"
echo "using your mirror to distribute trojans."
if am_root; then
echo "The files have been renamed to have the extension .FAILED and"
echo "will be ignored by apt."
cat BAD | while read a; do
mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
done
fi) | fmt
echo
sed 's/^/ /' < BAD
echo
fi
if grep -q ^ MISSING; then
allokay=false
(echo "The following files from /var/lib/apt/lists were missing. This"
echo "may cause you to miss out on updates to some vulnerable packages."
) | fmt
echo
sed 's/^/ /' < MISSING
echo
fi
if grep -q ^ NOCHECK; then
allokay=false
(echo "The contents of the following files in /var/lib/apt/lists could not"
echo "be validated due to the lack of a signed Release file, or the lack"
echo "of an appropriate entry in a signed Release file. This probably"
echo "means that the maintainers of these sources are slack, but may mean"
echo "these sources are being actively used to distribute trojans."
if am_root; then
echo "The files have been renamed to have the extension .FAILED and"
echo "will be ignored by apt."
cat NOCHECK | while read a; do
mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
done
fi) | fmt
echo
sed 's/^/ /' < NOCHECK
echo
fi
if $allokay; then
echo 'Everything seems okay!'
echo
fi
rm -rf /tmp/apt-release-check
</example>
<p>Es posible que necesite aplicar el siguiente parche para <em>sid</em> puesto
que <prgn>md5sum</prgn> añade un '-' tras la suma cuando la entrada es stdin:
<example>
@@ -37,7 +37,7 @@
local LOOKUP="$2"
Y="`get_md5sumsize Release "$LOOKUP"`"
- Y="`echo "$Y" | sed 's/^ *//;s/ */ /g'`"
+ Y="`echo "$Y" | sed 's/-//;s/^ *//;s/ */ /g'`"
if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
if [ "$Y" = "" ]; then
@@ -55,7 +55,7 @@
return
fi
X="`md5sum < /var/lib/apt/lists/$FILE` `wc -c < /var/lib/apt/lists/$FILE`"
- X="`echo "$X" | sed 's/^ *//;s/ */ /g'`"
+ X="`echo "$X" | sed 's/-//;s/^ *//;s/ */ /g'`"
if [ "$X" != "$Y" ]; then
echo "$FILE" >>BAD
echo "BAD"
</example>
<sect1 id="check-non-debian-releases">Comprobación de Release en fuentes que no
sean de Debian
<P>Observe que, cuando utilice la última versión de apt (con <em>apt
seguro</em>) no se requerirá un esfuerzo adicional por su parte a menos que
utilice fuentes que no sean de Debian, en cuyo caso apt-get requerirá un paso de
confirmación extra. Esto se evita proporcionando los archivos
<file>Release</file> y <file>Release.gpg</file> entre las fuentes que no son de
Debian. El archivo <file>Release</file> puede generarse con
<prgn>apt-ftparchive</prgn> (disponible en <package>apt-utils</package> 0.5.0 y
posteriores), el archivo <file>Release.gpg</file> es únicamente una firma
aparte. Para generar ambos siga este sencillo procedimiento:
<example>
$ rm -f dists/unstable/Release
$ apt-ftparchive release dists/unstable > dists/unstable/Release
$ gpg --sign -ba -o dists/unstable/Release.gpg dists/unstable/Release
</example>
<sect1 id="check-pkg-sign">Esquema alternativo de firma por paquetes
<p>El esquema adicional de firmar todos y cada uno de los paquetes permite que
se puedan comprobar éstos cuando no están referenciados en ningún archivo
<file>Packages</file> existente, y también permite utilizar en Debian paquetes
de terceros para los que nunca existieron archivos <file>Packages</file>, aunque
no estarán en el esquema predeterminado.
<p>Este esquema de firma de paquetes puede implementarse utilizando
<package>debsig-verify</package> y <package>debsigs</package>. Estos dos
paquetes pueden firmar y verificar firmas incorporadas en el propio .deb. Debian
tiene ya la capacidad de hacer esto, pero no hay ningún plan para implementar
las directrices u otras herramientas puesto que se prefiere el esquema de firmas
del repositorio. Estas herramientas están disponibles para usuarios y
administradores de repositorios que prefieran utilizar este esquema en su lugar.
<p>Las últimas versiones de <prgn>dpkg</prgn> (desde la 1.9.21) incorporan un
<url
id="http://lists.debian.org/debian-dpkg/2001/debian-dpkg-200103/msg00024.html";
name="parche"> que proporciona esta funcionalidad en el instante que se instala
<package>debsig-verify</package>.
<p>NOTA: Actualmente <file>/etc/dpkg/dpkg.cfg</file> viene con "no-debsig" en su
forma predeterminada.
<p>NOTA2: Las firmas de los desarrolladores no están presentes actualmente
cuando se introduce un paquete en el repositorio, puesto que el método preferido
es el de comprobación de versiones que se describió previamente.
Reply to: