Razones para deshabilitar / habilitar SELinux

36

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 ;-)

wzzrd
fuente

Respuestas:

25

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.

tylerl
fuente
8
Un proveedor de software "empresarial" contratado para instalar su producto manejó un problema de permisos al hacer un chmod -R 777 * en un gran árbol de directorios. Realmente no les importa tu seguridad.
kmarsh
21

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.

Ofidia
fuente
16

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:

jtimberman
fuente
2
+1, información muy útil.
DCookie el
10

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.

Jason Tan
fuente
2
+1 para señalar que a menudo le conviene dejar SELinux en funcionamiento y solo apagarlo para verificar si es el origen de un problema.
Ophidian
2

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

LiraNuna
fuente
Interesante. ¿En qué distribución estás? Nunca he usado AppArmor, pero tengo curiosidad por saber qué distribución tiene configurada de fábrica y cuáles son las características. Investigará esto. Personalmente, no tengo problemas con SELinux, por cierto, pero me cuesta un poco acostumbrarme.
wzzrd
AppArmor fue desarrollado originalmente por Novell y se incluye por defecto en todas sus distribuciones openSUSE y SUSE Linux Enterprise. Está habilitado de forma predeterminada en las distribuciones de Enterprise, y es fácil de activar en las distribuciones de los consumidores. Ubuntu lo ha tenido desde 7.04, pero no aplica automáticamente todas las aplicaciones de forma predeterminada.
andrewd18
Creo que recuerdo haber hablado sobre Novell despidiendo a la mayoría del equipo de AppArmor. ¿Ubuntu no lo dejó caer de la distribución? ¿O estoy escuchando las voces en mi cabeza otra vez? ;-)
wzzrd
Novell lo hizo, pero el autor todavía trabaja en él sin pagar. Todavía es compatible con ubuntu, y cosas como cups y mysqld se aplican de manera predeterminada.
LiraNuna
No siempre, pero a menudo, intercambiamos la facilidad de uso por seguridad y viceversa. Es un acto de equilibrio y la respuesta no es trivial debido principalmente a que definir riesgos y objetivos de seguridad es una tarea muy difícil.
rev
1

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.

Federico
fuente
En realidad, hay casos en los que SELinux puede interferir con las aplicaciones en modo Permisivo. Uno: en algunos momentos, se aplican algunas reglas, a pesar de que el sistema se establece como permisivo. No estoy seguro si este sigue siendo el caso. Dos: el tiempo necesario para procesar las reglas puede ser suficiente para arruinar el IPC. He visto esto con los clústeres de Oracle. Nuevamente en el pasado y no estoy seguro de cuál es el estado actual. Pero recuerde que casi todas las llamadas al sistema tienen un pequeño tiempo de procesamiento agregado.
Jason Tan
0

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.

cosa muy pegajosa
fuente
No creo que Oracle es compatible oficialmente SELinux Tho
wzzrd