¿Que es eso? Pues es un parche la mar de chulo para el tema de la seguridad. Permite, entre otras cosas:

• Socket ACLs
Eso es bastante interesante. Apache, bind, INN, y un monton de procesos tiene que tener un parte ejecuntandose como root, por que sino no pueden abrir el puerto que necesitan (para abrir un puerto menos que el 1024 necesias ser root). Con listas de control de acceso, esto no seria necesario. Podriamos darle al usuario www-data permiso para abrir el puerto 80, y listo.
• Chroot restrictions
Chroot es una llamada curiosa. Permite enjaular un proceso de tal forma que se ejecute en un entorno controlado y cerrado. Esto a primera vista estaria muy bien, sino fuera por que hay algunos flecos en la defincion de chroot en el estandar. Uno de ellos, es que se debe permitir una salida a root. Esto es mortal. Con alguien consiga root dentro de un chroot, no sirve de nada la jaula, motivo por el cual, en FreeBSD a parte de chroot, tienen jail.

Pues bien, con estas opciones del grsecurity podemos limitar bastante las posibilidades de escape de la jaula.

Por ejmeplo, tiene la opcion de no poder ejecutar ptrace sobre un proceso fuera de la jaula por que se puede inyectar codigo sobre ese proceso y conseguir salirse.

• PID, puertos TCP y numeros de secuencia de TCP aleatorios
Bueno, estas caracteristicas necesitan poca explicacion.Quiza el "mas raro" sea el de los PID. Tener PID aletorios nos permite dificultar algunos ataques que requiere conocer el PID de un proceso (como el del ptrace anterior).
• No kernel modification via /dev/mem, /dev/kmem, or /dev/port
Esos dispositivos tienen como permisos 640 root.kem asi que podriamos pensar que estamos a salvo, no?. Que yo sepa, el motivo de ese parche es evitar troyanizar el kernel incluso si tenemos el soporte de modulos desactivado.
• Pax
PaX permite a las arquitecturas que no tiene la posibilidad de limitar de forma fina los permisos sobre las paginas el poder saltarse esa limitacion.Así, de esta forma podemos tener la pila no ejecutable (que nos salvaria el culo algunas veces,aunque no siempre). En la seccion de PaX de grsecurity ponen mas cosas, pero como no estoy seguro de algunas cosas aun, pues no las comento.

Otro parche interesante es LIDS. Este parche creo que lo empeceron a crear debido al excesivo poder que tiene root en una maquina. Si alguien se hacia root, estabas perdido. Pues bien, una de las caracteristicas de este parche, es que incluso root puede tener el poder limitado Ojeando un poco la pagina web, se puede intuir que LIDS esta basando en el sistema de capabilities del kernel y en un par de aplicaciones en espacio de usuario (lidsadm y lidsconf) que se usan para configurar todo. Lids permite cosas como:

• Esconder directorios
• Limitar la lectura de archivos/directorios
• Limitar a que puertos puede abrir un proceso
• Configurar alertas de seguridad
• Solo poder añadir informacion a los logs, nunca borrar y nada similar

En la Faq de LIDS hay ejemplos de configuracion para diversas situaciones (qmail, exim, posftix, mysql, ssh, etc, etc).

Para termiar mis notas sobre LIDS, acaba de salir un libro que pinta muy bien, aunque esta en aleman. Intrusion Linux Detection für Linux server

Tambien seria interesante tener un sistema de archivos cifrado. Si, ya se que esta el cryptoloop, pero que pasa si queremos tener los $HOME's en remoto?

OpenBSD sino recuerdo mal incorpora TCFS. En esa web podemos encontrar tambien parches para Linux, pero que yo sepa, solo estan probados para i386 y no parece que haya parche para 2.4.

Tambien tenemos StegFS aunque por los comentarios leidos en slashdot en esta noticia

Eso era en cuanto a sistemas de archivos cifrados, pero tambien hay un par de sistemas de archivos distribuidos bastante interesantes. Lustre y PFVS.

PVFS fue una opcion que estuvimos tanteando en Lilo para tener acceso a los $HOME independientemente de la maquina en la que hicieramos login. La otra opcion era poner NFS.

La idea de PVFS es justamente la contraria a NFS. En lugar de tener un unico nodo donde se almacenan los datos, se tienen una serie de nodos, que bien pueden ser las mismas maquinas con las que trabajas de forma habitual, en donde se reparte de cierta manera los datos del usuario. De esta forma se intenta paliar los cuellos de botella que suelen ser los sistemas tradicionales de I/O. No pudimos probar el rendimiento de esta solucion por que el parche tenia cierta dependencia de 80x86.

Sobre lustre, poco puedo decir, por que me lo he encontrado hoy mientras buscaba el nombre del sistema de archivos basado en esteanografia, que no recordaba como se llamaba.