¿Por qué hay un repositorio de paquetes separado para las actualizaciones de seguridad de Debian?

¿Por qué no suben paquetes al repositorio de paquetes normal? ¿Es esta una convención general (es decir, otras distribuciones también separan los repositorios)?

debian repository

— tshepang
fuente

Sugeriría no tener otras distribuciones ya que eso podría ser excesivamente largo, también por archivo, ¿quieres decir repositorio de paquetes? Supongo que sí, pero asegurándome de no significar una rama svn / git o algo así.

— xenoterracide el

debian.org/security

— Daniel Dinnyes

Respuestas:

Debian tiene un canal de distribución que proporciona actualizaciones de seguridad solo para que los administradores puedan elegir ejecutar un sistema estable con solo el mínimo absoluto de cambios. Además, este canal de distribución se mantiene algo separado del canal normal: todas las actualizaciones de seguridad se alimentan directamente security.debian.org, mientras que se recomienda usar espejos para todo lo demás. Esto tiene una serie de ventajas. (No recuerdo cuáles de estas son motivaciones oficiales que leí en las listas de correo de Debian y cuáles son mi propio mini análisis. Algunas de ellas se mencionan en las Preguntas frecuentes de seguridad de Debian ).

Las actualizaciones de seguridad se distribuyen de inmediato, sin la demora incurrida por las actualizaciones espejo (que pueden agregar aproximadamente 1 día de tiempo de propagación).
Los espejos pueden quedar rancios. La distribución directa evita ese problema.
Hay menos infraestructura para mantener como servicio crítico. Incluso si la mayoría de los servidores de Debian no están disponibles y las personas no pueden instalar nuevos paquetes, siempre que security.debian.orgapunten a un servidor que funcione, se pueden distribuir actualizaciones de seguridad.
Los espejos pueden verse comprometidos (esto ha sucedido en el pasado). Es más fácil ver un único punto de distribución. Si un atacante logra cargar un paquete malicioso en algún lugar, security.debian.orgpodría enviar un paquete con un número de versión más reciente. Dependiendo de la naturaleza del exploit y la puntualidad de la respuesta, esto podría ser suficiente para mantener algunas máquinas sin infectar o al menos advertir a los administradores.
Menos personas tienen derechos de carga security.debian.org. Esto limita las posibilidades de que un atacante intente subvertir una cuenta o máquina para inyectar un paquete malicioso.
Los servidores que no necesitan acceso web ordinario pueden mantenerse detrás de un firewall que solo permite el acceso security.debian.org.

— Gilles 'SO- deja de ser malvado'
fuente

El repositorio de seguridad es anterior a la firma de los archivos de lanzamiento para los repositorios, por lo que se desaconsejó reflejarlo, ya que diluyó la confianza implícita de la descarga desde security.debian.org. Ese argumento ha desaparecido hasta cierto punto ahora que los metadatos del paquete están firmados.

— jmtd

El host se security.debian.orgresuelve en un grupo de direcciones, por lo que tal vez sea un grupo de máquinas, incluso si técnicamente no tiene espejos.

— Faheem Mitha

Estoy bastante seguro de que Debian también incluye actualizaciones de seguridad en el repositorio regular.

La razón para tener un repositorio separado que solo contenga actualizaciones de seguridad es para que pueda configurar un servidor, solo apuntarlo al repositorio de seguridad y automatizar las actualizaciones. Ahora tiene un servidor que garantiza tener los últimos parches de seguridad sin introducir errores causados accidentalmente por versiones incompatibles, etc.

No estoy seguro de si este mecanismo exacto es utilizado por otras distribuciones. Hay un yumcomplemento para manejar este tipo de cosas para CentOS, y Gentoo actualmente tiene una lista de correo de seguridad ( portageactualmente se está modificando para admitir actualizaciones solo de seguridad). FreeBSD y NetBSD proporcionan formas de realizar auditorías de seguridad de los puertos / paquetes instalados, que se integran bien con los mecanismos de actualización incorporados. En total, el enfoque de Debian (y probablemente el de Ubuntu, ya que están tan estrechamente relacionados) es una de las soluciones más ingeniosas para este problema.

— Hank Gay
fuente

Sí, porque un parche de seguridad nunca podría introducir otro error.

— xenoterracida

"s. Ahora tiene un servidor que está garantizado para tener los últimos parches de seguridad sin introducir accidentalmente errores causados por versiones incompatibles, etc." ¿No es eso lo que eso significa? Supongo que podría decir que las versiones incompatibles son el punto discutible ... qué significa eso exactamente ... la mayoría de las veces las personas que solo soportan parches de seguridad no lo hacen porque sienten que ABI / API es lo único que estás mirando.

— xenoterracide

@xeno ¿Está criticando la idea de dividir estos repositorios o nos está alertando de que no hay garantías?

— tshepang

@xeno Dependiendo de cómo maneje las cosas el flujo ascendente, los parches de corrección de errores pueden ser demasiado intrusivos para una versión 'estable'.

— tshepang el

La gran mayoría de los parches de seguridad son trivialmente pequeños: reordenar los argumentos a un memset, arreglar una verificación de límites en un strncmp o what-have-you. Por supuesto, podrían introducir otros errores, pero el riesgo es muy pequeño y teórico, mientras que el error de seguridad descubierto es muy práctico.

— jmtd

Ayuda con dos cosas:

seguridad: primero obtenga sus soluciones de seguridad, luego corre menos riesgos al actualizar el resto
las actualizaciones de seguridad deben almacenarse a un alto nivel de seguridad, ya que tiende a confiar en ellas para proteger el resto de su sistema, por lo que podría ser que este repositorio tenga controles de seguridad más fuertes para evitar compromisos

bien podría haber otras razones, pero esas son las dos que me serían útiles

— Rory Alsop
fuente

¿Estás seguro de almacenado en un alto nivel de seguridad ? Lo digo porque expresas dudas, podría ser .

— tshepang

Tshepang bien visto: no tengo visibilidad del entorno en el que existe el repositorio, pero de esa manera lo configuraría :-)

— Rory Alsop

Hay al menos alguna forma de mayor nivel de seguridad: solo el equipo de seguridad puede impulsar un paquete security.debian.org. No conozco los detalles de implementación.

— Gilles 'SO- deja de ser malvado'