Razones para deshabilitar / habilitar SELinux

En la línea de esta pregunta sobre StackOverflow y la multitud completamente diferente que tenemos aquí, me pregunto: ¿cuáles son sus razones para desactivar SELinux (suponiendo que la mayoría de la gente todavía lo haga)? ¿Te gustaría mantenerlo habilitado? ¿Qué anomalías has experimentado al dejar SELinux activado? Además de Oracle, ¿qué otros proveedores tienen problemas para admitir sistemas con SELinux habilitado?

Pregunta adicional: ¿Alguien ha logrado que Oracle se ejecute en RHEL5 con SELinux en la aplicación de modo dirigido? Quiero decir, estricto sería increíble, pero no lo sé, ni siquiera es remotamente posible, así que sigamos con el objetivo primero ;-)

RedHat activa SELinux de forma predeterminada porque es más seguro. Casi todos los proveedores que utilizan productos derivados de Redhat desactivan SELinux porque no quieren tener que dedicar tiempo (y, por lo tanto, dinero) para descubrir por qué no funciona. La gente de Redhat / Fedora ha invertido una gran cantidad de tiempo y esfuerzo haciendo de SELinux una opción más viable en la empresa, pero no muchas otras organizaciones realmente se preocupan por su seguridad. (Se preocupan por su seguridad y la reputación de seguridad de su producto, que es una cosa totalmente diferente).

Si puedes hacer que funcione, entonces hazlo. Si no puede, entonces no espere mucha ayuda de los vendedores. Probablemente pueda obtener ayuda de los muchachos de Redhat / Fedora, de las listas de correo de selinux y del canal #selinux en freenode. Pero de compañías como Oracle, bueno, SELinux realmente no tiene en cuenta su plan de negocios.

Por lo general, es mejor ejecutar SELinux en Permisivo en lugar de deshabilitarlo por completo. Luego puede verificar (vía audit2why) después de un tiempo para ver qué tipos de violaciones se habrían denegado durante su uso habitual, y crear políticas personalizadas audit2allowsi esas 'violaciones' son falsos positivos para su configuración.

He encontrado que el comportamiento de SELinux en sistemas no derivados de Fedora es significativamente más sensible que el que se obtiene con un sistema Fedora / RHEL típico de forma predeterminada.

Si aún no lo ha visto, puede encontrar la Guía del usuario de Fedora SELinux educativa.

Razones para:

• Mayor nivel de seguridad a través del control de acceso obligatorio.
• ¿Necesita una razón más allá del mayor nivel de seguridad? :-)

Razones contra:

• Difícil de comprender
• Difícil de manejar
• Difícil de solucionar

Dicho esto, si está considerando SELinux, le recomiendo el libro SELinux por ejemplo .

Trabajé para una empresa que tenía habilitado SELinux, en modo obligatorio, en todos los sistemas. La clave para nosotros fue comprender y usar el programa audit2allow que se puede usar para crear nuevas reglas de contexto.

Primero, generaríamos una plantilla con audit2allow, y luego usaríamos un script para compilarla, así:

export NAME="my_serviced"
sudo audit2allow -m "${NAME}" -i /var/log/audit/audit.log > ${NAME}.te
sudo setup_semodule ${NAME}

El script setup_semodule:

#!/bin/sh

# Where to store selinux related files
SOURCE=/etc/selinux/local
BUILD=/etc/selinux/local
NAME=$1

/usr/bin/checkmodule -M -m -o ${BUILD}/${NAME}.mod ${SOURCE}/${NAME}.te
/usr/bin/semodule_package -o ${BUILD}/${NAME}.pp -m ${BUILD}/${NAME}.mod
/usr/sbin/semodule -i ${BUILD}/${NAME}.pp

/bin/rm ${BUILD}/${NAME}.mod ${BUILD}/${NAME}.pp

Esto crea el módulo a partir de la plantilla (archivo .te), genera un paquete y luego carga el módulo.

Utilizamos Puppet para nuestro sistema de gestión de configuración, y escribimos configuración para Puppet para gestionar todo esto.

Módulo de marionetas de SELinux:

• http://github.com/sansnoc/puppet/tree/master/selinux

La razón para desactivarlo es porque puede ser una tarea difícil de depurar.

Sin embargo, no lo apagamos ahora. Casi siempre lo mantenemos en funcionamiento. Ocasionalmente lo apago para verificar rápidamente si SElinux es un problema o no.

Es mucho más fácil depurar ahora, especialmente si te familiarizas con audit2allow. Realmente no necesita comprenderlo con audit2allow, pero a veces puede terminar abriéndose más de lo que cree con audit2allow. Habiendo dicho eso, algunos SELinux son mejores que ninguno.

De ninguna manera soy un experto de SELinux y solo lo he estado usando durante un par de años. Todavía no entiendo los conceptos básicos, pero sé lo suficiente como para ejecutar aplicaciones, incluidas las incluidas en la distribución y las cosas aleatorias compiladas de la red.

Lo más importante que he tenido a su uso son ls -lZ(contexto SELinux espectáculo), audit2allow, chcon, semodule, getenforce, setenforcey booleanos. Con esas herramientas he logrado obtener todas las aplicaciones que necesitaba para ejecutarse con SELinux.

Me parece que uno de los grandes problemas con la depuración de los problemas de SELinux es simplemente recordar comprobar si hay problemas de SELinux cuando tengo otros problemas inexplicables. Por lo general, me lleva un poco de tiempo decir "¡¡¡¡¡cheque SELinux !!".

Según la página de manual de bind, SELinux es mucho más seguro que ejecutar bind en una cárcel chroot. Muchas otras personas que tienen mucha más pista de la que yo también recomiendo, lo corro a ciegas ahora. Y sospeche que a pesar del problema ocasional, probablemente valga la pena hacerlo.

Inhabilité SELinux para AppArmor , lo encontré mucho más amigable y fácil de mantener que SELinux.

No hay razón para desactivarlo cuando puede ejecutarlo en modo Permisivo. No interferirá con la aplicación en ejecución y seguirá proporcionando un registro de seguridad útil. La única excepción es sobre los contextos de usuario: si está cambiando entre diferentes usuarios que viven dentro de otra instancia de Linux que se ejecuta en un chroot, podría tener problemas.

SE Linux ya no es tan hostil como solía ser, al menos no está en distribuciones compatibles comercialmente como RHEL5. En su mayor parte, puede dejarlo encendido, y estará bien con cualquier cosa provista por RedHat. Con cualquier otra cosa puede ser variable. El problema es que el trabajo de servicio profesional para hacer que las aplicaciones funcionen con SE Linux habilitado es un buen flujo de ingresos para compañías como RedHat y Oracle, por lo que no tienen incentivos para hacer que todo funcione bien.