tech

Una de las cosas que más se le acusa a gentoo es el no estar preparado para utilizarlo en servidores, y a causa de eso, no está muy extendido en ese campo. Sin embargo, son grandes los esfuerzos que se están haciendo para conseguirlo.
Buena prueba de estos esfuerzos es la existencia de un sistema de actualizaciones de seguridad, que ya lleva algún tiempo utilizándose pero que yo estoy implantando ahora.
Las actualizaciones de seguridad requieren de dos cosas: Un sistema para generar alertas de seguridad, y una forma de actualizar nuestra instalación sin actualizar el sistema completo.
En cuanto a la primera parte, gentoo ha creado la lista de “glsa” (http://www.gentoo.org/security/en/glsa/). GLSA son las siglas de “Gentoo Linux Security Advisories”, y como su propio nombre indica, son los avisos de seguridad de gentoo. Cuando se reporta un fallo de seguridad en un paquete (desde la propia gente de Gentoo o desde los desarrolladores del programa), se crea un aviso de GLSA. El anuncio se publica en la lista de correo GLSA (y también en gentoo-announce@gentoo.org), indicando que hacer para solucionar el error, si existe o no una actualización y el motivo del error (sólo una breve descripción para evitar que se haga mal uso de esa información). Cada GLSA se identifica con un código basado en la fecha: AñoMes-Fecha.
Para actualizar nuestra instalación, podemos hacer manualmente los cambios, pero eso sería inviable para un servidor, ya que significaría tener que estar pendiente de la información y de los pasos para actualizarla.
Como eso no es posible, existe el programa “glsa-check”, que funciona al estilo de apt-get update en debian (aunque no exactamente igual).
glsa-check se utiliza siempre con un primer parámetro que es el modo de ejecución y el segundo parámetro que es la lista de glsa a usar.
Los parámetros a destacar son “-l” y “-f”.

“-l”, lista los glsa y el segundo los aplica. Si no tiene parámetros, lista todos los glsa existentes y no aplicados
“-f” aplica los glsa de la lista.

La lista puede ser una serie de identificadores de GLSA o bien una de tres palabras clave: “all” , “new” y “affected”. Con all, la acción especificada se aplica a todos los glsa disponibles. Con new sólo a los recientes desde la última comprobación. Con affected (y este es el interesante), el comando se aplica a los glsa que afectan a nuestro sistema.
Por ejemplo:

Encrucijada alu3066 # glsa-check -l affected
[A] means this GLSA was already applied,
[U] means the system is not affected and
[N] indicates that the system might be affected.

200701-10 [A] WordPress: Multiple vulnerabilities ( www-apps/wordpress )

Como vemos, hemos listado los glsa que afectan a nuestro sistema. En este caso, sólo aparece uno (wordpress), con la letra [A], que significa que ya está aplicado. Utilizando “glsa-check -f affected” , aplicaríamos los glsa que afectan al sistema (lo que habitualmente consiste en actualizar un paquete).
La ventaja que tiene éste método frente a un típico update es que se limita a actualizar ese paquete, evitando pulular por dependencias siempre que puede, y también que permite automatizarlo fácilmente. Por ejemplo, yo lo he puesto en un cron.daily:

#! /bin/sh
emerge sync
glsa-check -f affected

Efectivamente, glsa-check depende de la actualización del árbol del portage, así que hay que actualizarlo frecuentemente para que tenga sentido.
No todo es de color de rosas, no. glsa-check no está terminado. Está pendiente de ser incorporado al emerge y todavía da falsos positivos, entre otras cosas, porque no tiene en cuenta los slots de los paquetes (es posible que un paquete tenga el fallo únicamente si tiene el soporte para un determinado programa). Sin embargo, es una utilidad interesante para la gestión de la seguridad en nuestra distribución favorita, y un paso más a su integración en entornos de servidor, ¡donde no es factible hacer un emerge world todos los días!