Ejemplo de seguridad de la vida real de SELinux?

¿Alguien puede dar un ejemplo de la vida real de dónde SELinux guardó su tocino de seguridad? (o AppArmour si lo desea). Si no es el tuyo, ¿un puntero a alguien con una experiencia creíble?

No es una prueba de laboratorio, no es un documento técnico, no es una práctica recomendada, no es un aviso del CERT, sino un ejemplo real, algo así como audit2 ¿por qué muestra un intento de piratería real detenido en seco?

(Si no tiene ningún ejemplo, guarde comentarios en los comentarios en lugar de Respuestas).

¡Gracias!

¿Qué tal esto de Russell Coker ? Es un ejemplo de la vida real, ya que ha invitado a todos a su máquina como root. A primera vista, pensé que esto era una locura, pero luego te das cuenta del poder de SELinux para hacer que la raíz sea algo inútil.

Aquí hay algunos ejemplos de la vida real de su sitio.

SELinux no se trata necesariamente de protección contra hackers; se trata de documentar y aplicar políticas sobre cómo se comporta un sistema. Es una herramienta en la caja de herramientas que es valiosa, pero requiere habilidad para usarla bien.

Un ejemplo de la vida real de cómo te salva es algo como esto:

Una vulnerabilidad en un demonio FTP permite que un usuario anónimo obtenga privilegios de root. Un atacante usa esa vulnerabilidad para acceder a los directorios de inicio de los usuarios y robar claves privadas SSH, algunas de las cuales no tienen una frase de contraseña.

Si SELinux está configurado para no permitir la política "Permitir que los servicios ftp lean y escriban archivos en los directorios de inicio de los usuarios", la explotación no tendrá éxito y se registrará la violación de la política.

Aquí hay una descripción detallada de un ataque que SELinux detuvo en seco, con detalles de registro y una explicación de las técnicas forenses utilizadas. Tengo este artículo publicado en Linux Journal:

http://www.linuxjournal.com/article/9176

Aquí hay un extracto del principio:

Si opera servidores conectados a Internet, es probable que eventualmente tenga que lidiar con un ataque exitoso. El año pasado, descubrí que a pesar de las defensas de varias capas en un servidor web de prueba (targetbox), un atacante había logrado utilizar un exploit en un intento parcialmente exitoso de obtener acceso. Este servidor ejecutaba Red Hat Enterprise Linux 4 (RHEL 4) y el sistema de gestión de contenido Mambo. Tenía múltiples defensas en su lugar, incluido Linux con seguridad mejorada (SELinux). SELinux evitó que el atacante ejecutara la segunda etapa del ataque, posiblemente evitando un compromiso de raíz.

Este artículo presenta un estudio de caso de la respuesta a la intrusión, explicando cómo descubrí la intrusión, qué pasos tomé para identificar el exploit, cómo me recuperé del ataque y qué lecciones aprendí con respecto a la seguridad del sistema. He cambiado los nombres de las máquinas y las direcciones IP por razones de privacidad.