SELinux vs. AppArmor vs. grsecurity [cerrado]

Cerrada . Esta pregunta necesita estar más centrada . Actualmente no está aceptando respuestas.

¿Quieres mejorar esta pregunta? Actualice la pregunta para que se centre en un problema solo editando esta publicación .

Cerrado hace 2 años .

Tengo que configurar un servidor que sea lo más seguro posible. ¿Qué mejora de seguridad usarías y por qué, SELinux, AppArmor o grsecurity? ¿Me puede dar algunos consejos, sugerencias, pros / contras para esos tres?

HASTA DONDE SE:

SELinux: más potente pero más complejo
AppArmor: configuración / gestión más simple que SELinux
Seguridad: configuración simple debido al entrenamiento automático, más funciones que solo control de acceso

linux security hardening

¿Un "servidor" para proporcionar qué tipo de servicio? ¿A qué público, en qué entorno? ¿Qué constituye "seguro" para usted en este contexto? Sería necesaria mucha más información para proporcionar una respuesta útil. Por ejemplo, un servidor de hora del día IP puro puede ser muy seguro: todo el firmware de ROM, entrada de radio, batería autónoma con carga automática. Pero esa probablemente no sea una respuesta útil para usted. Entonces, ¿qué tipo de servicio? ¿Equipo de trabajo confiable en toda la empresa, en toda la empresa, redes dedicadas punto a punto, etc.? ¿Es necesaria una alta disponibilidad? ¿Fiabilidad? ¿Integridad de los datos? ¿Control de acceso? Give

— mpez0

Respuestas:

He investigado mucho en esta área. Incluso he explotado los conjuntos de reglas de AppArmor para MySQL . AppArmor es la forma más débil de separación de procesos. La propiedad que estoy explotando es que todos los procesos tienen privilegios de escritura en algunos de los mismos directorios, como /tmp/. Lo bueno de AppArmor es que rompe algunas vulnerabilidades sin interferir en la forma de usuarios / administradores. Sin embargo, AppArmor tiene algunos defectos fundamentales que no se solucionarán pronto.

SELinux es muy seguro, también es muy molesto. A diferencia de AppAmoror, las aplicaciones más legítimas no se ejecutarán hasta que SELinux se haya reconfigurado. En la mayoría de los casos, esto da como resultado que el administrador configure incorrectamente SELinux o lo deshabilite todo junto.

grsecurity es un paquete muy grande de herramientas. El que más me gusta es el chroot mejorado de grsecuirty. Esto es aún más seguro que SELinux, aunque se necesita algo de habilidad y tiempo para configurar una cárcel chroot donde SELinux y AppAprmor "simplemente funcionan".

Hay un cuarto sistema, una máquina virtual. Se han encontrado vulnerabilidades en entornos de VM que pueden permitir que un atacante "explote". Sin embargo, una VM tiene una separación aún mayor que un chroot porque en una VM está compartiendo menos recursos entre procesos. Los recursos disponibles para una VM son virtuales y pueden tener poca o ninguna superposición entre otras VM. Esto también se relaciona con la <buzzword>" computación en la nube " </buzzword>. En un entorno de nube, podría tener una separación muy clara entre su base de datos y la aplicación web, lo cual es importante para la seguridad. También es posible que 1 exploit sea el propietario de toda la nube y de todas las máquinas virtuales que se ejecutan en ella.

— Torre
fuente

en lugar de la <buzzword>etiqueta puedes escribir "mi trasero", todos sabrán a qué te refieres;)

— Daniel Dinnyes

Por VM, ¿te refieres a Xen, KVM o LXC / Docker? Además, por favor haga referencia a sus evaluaciones.

— Daniel Dinnyes

@Daniel Dinnyes no hay referencias aquí, esta es toda una opinión personal como un hacker que ataca las aplicaciones modernas que están protegidas con estas técnicas de mitigación; lo importante es que nada es perfecto.

— Torre

@Daniel Dinnyes Si está interesado en casos de mal uso, comience con los casos de uso previstos. Instale distribuciones que usen estas tecnologías e implemente aplicaciones en ellas. Lea sobre la implementación y configuración de estos sistemas de seguridad y luego busque debilidades.

— Torre

@Daniel Dinnyes mira los CVE emitidos y especialmente cualquier exploits público para cada plataforma. Recientemente se encontró un bypass de SELinux realmente bueno: exploit-db.com/exploits/40419

— Rook

Personalmente, usaría SELinux porque terminaría apuntándome a un poco de sabor de RHEL, que tiene esta configuración lista para usar en su mayor parte. También hay un conjunto receptivo de mantenedores en Red Hat y mucha documentación muy buena sobre la configuración de SELinux. Enlaces útiles a continuación.

— Ofidia
fuente

sí, pero ñam y selinux son tan molestos.

— Torre

Encuentro la CLI de yum significativamente más intuitiva que apta. SELinux es molesto cuando intentas seguir tu propio camino con aplicaciones que no son de stock, pero nunca he tenido problemas con las cosas de stock más allá de la necesidad de activar algunos sebool para habilitar la funcionalidad no predeterminada (por ejemplo, permitir que los scripts httpd php se conecten a la base de datos)

— Ophidian