Información general

Introducción

A causa de nuestro reciente problema de seguridad, ha sido obvio que nada mejor que una rigurosa revisión de seguridad en todo el código fuente del sistema.

La ingente cantidad de código de fuentes externas en FreeBSD hace especialmente sencillo que algunos problemas de seguridad puedan pasar desapercibidos hasta que sea demasiado tarde, y hasta estos momentos no se ha realizado ningún esfuerzo verdaderamente importante de revisión de todo el código del sistema centrado en la seguridad. Esta situación debe cambiar ahora, ya que si esperamos ser el sistema operativo en el que la gente pueda confiar mientras Internet sigue creciendo y (sospecho) volviendose má hostil para sistemas mal protegidos. Una buena seguridad es algo a realizar y compartir entre el administrador local y los desarrolladores del sistema, y éstos tienen *ahora* que hacer su parte.

El primer paso del core team respecto al tema de la seguridad fue crear un puesto de responsable de seguridad, Guido van Rooij, para que una de las "voces de la mesa" tuviese la seguridad como su principal responsabilidad y representar a FreeBSD en las listas externas más importantes relacionadas con la seguridad. Además él nos mantendrá más informados sobre los temas de seguridad para que no nos vuelva a coger desprevenidos como ocurrió alguna vez en el pasado.

Nuestro segundo paso es esta auditoría, un intento de ir metodicamente a través de cada una de las líneas de código de FreeBSD prestando especial atención a buffer overflows obvios (sprintf()/strcpy() vs snprintf()/strncpy() ), problemas de seguridad menos obvios, secciones de insuficiente código defensivo, etc.

Usando la base de datos de módulos como guí, distribuiremos los fuentes en partes má manejables, manteniendo un ídice en un lugar prominente para que la gente pueda ver los módulos que se han cubierto y los que no. Un equipo cuidadosamente seleccionado ha sido formado, siendo "auditotes" y "revisores". La principal responsabilidad de un auditor, la cual debe ser compartida con otro auditor, es revisar el código en busca de posibles agujeros o bugs. Una vez existe una razonable cantidad de código acumulado, y suponiendo que no se haya encontrado ningún problema, éstos son enviados a uno o má "revisores" que se responsabilizan de volver a revisar el código una vez más.

Requerimientos:

Para ser auditor, deberís tener privilegios de "commit" en freefall.freebsd.org o un acuerdo con otro auditor/revisor que los tenga. También deberías usar, o tener acceso inmediato a FreeBSD-current ya que todas las revisiones y cambios se realizarás sobre esta rama en primer lugar.

Qué buscar y que reglas generales a seguir son suficientemente complejas como para explicarlas en La Guía de Seguridad de FreeBSD. Por favor, leela ahora si no lo habías hecho todavía. Otros excelentes documentos son Secure Programming Checklist y el Unix Security Checklist, ambos disponibles en AUSCERT.

Estructura:

Aquí está la estructura existente en estos momentos. Es *muy* esquemática actualmente, ya que acabamos de comenzar, y ha medida que la gente nos comunique los módulos que van a revisar o auditar iremos actualizandolo.

Nada en la base de datos de módulos representa un objetivo potencial de auditoría - desde los mas pequeños como "cat" hasta los más grandes como "lib", lo más importante es que la gente selecciones módulos que pueda manejar y asumir. Si coges 15 cosas y solo trabajas con 5, no estarás haciendo un favor a nadie ya que el resto de auditores que las 10 restantes están siendo trabajadas!.

Mención de Auditores/Revisores

Esta es la lista de personas que voluntariamente han participado como auditores o revisores en este proceso. Pueden ser localizados colectivamente enviando un mail a auditors@FreeBSD.org. Si solo quieres localizar a los auditores y revisores de una categoría específica, digamos usr.sbin por ejemplo, envía un mail a audit-usr.sbin@FreeBSD.org.

* = Tiene privilegios de "commit".