Sí, SELinux hace que Red Hat (y cualquier otra distribución de Linux que realmente lo use) sea más seguro, suponiendo que realmente esté en uso.
SELinux implementa el control de acceso obligatorio . Los permisos normales de Unix, las ACL, etc., implementan control de acceso discrecional . Los dos se complementan entre sí.
Para funcionar, SELinux requiere una política que defina qué acciones en el sistema pueden permitirse. Si bien es posible crear una política de sistema completa desde cero, la mayoría de las distribuciones de Linux incluyen una política basada en la llamada política de referencia . Esto significa, entre otras cosas, que la configuración de SELinux en todas las distribuciones será muy similar. (La mayoría de las distribuciones de Linux hacen que la política de referencia de SELinux esté disponible en sus repositorios de paquetes, aunque es posible que no se instale de manera predeterminada).
SELinux funciona mediante la restricción de usuarios y procesos para realizar solo las acciones permitidas en la política. Por defecto, la política es denegar, por lo que si la política no permite explícitamente una acción, entonces no sucede. Es por eso que a menudo tienes problemas con SELinux al rechazar algo que estás tratando de hacer.
En el lado positivo, esto también evita que las vulnerabilidades, incluso las exploits de 0 días, se salgan de control. Por ejemplo, si su servidor web (Apache) es explotado, el daño se limita solo a aquellas cosas a las que Apache puede acceder. No podría leer su /etc/shadowarchivo, por ejemplo, incluso con un exploit raíz remoto. Mientras que los permisos de Unix (DAC) permiten a la raíz leer el archivo, SELinux (MAC) no permite que el proceso comprometido salga de los límites.
El gran problema es que debe haber un módulo de política SELinux cargado para el servicio. Si instala un servicio en su caja que no incluye un módulo de política SELinux, se ejecutará sin restricciones y podrá hacer lo que quiera. SELinux no se aplicará a ello.
Otra cosa que debes saber es todo sobre los booleanos . Estos parámetros ajustables los proporcionan las políticas de SELinux para personalizarlos para instalaciones particulares y permitir o denegar el acceso según las necesidades de configuración local. Por ejemplo, puede dar acceso a Apache a los recursos compartidos de Samba, permitir que Samba comparta los directorios de inicio de los usuarios y muchas otras cosas potencialmente útiles que son necesarias para algunas configuraciones pero no para otras.
La mejor guía para SELinux que he visto actualmente es la Guía del usuario de Linux con seguridad mejorada de Red Hat . Le ayudará a ponerse en marcha rápidamente, así como a completar los detalles de fondo de lo que está sucediendo. También incluye una guía integral de solución de problemas que le ayuda a ejecutar su proceso con SELinux.
¿Es útil?
SELinux protege contra procesos (y usuarios, si ha confinado a sus usuarios) que hacen cosas inesperadas. Limita severamente el daño que puede hacer un exploit remoto. Si nunca ha sufrido un compromiso remoto, es (1) afortunado y (2) probablemente nuevo. Si ha trabajado un compromiso remoto, ciertamente no quiere que vuelva a suceder.
No es tan útil en un entorno hogareño , a menos que esté ejecutando servicios de Internet en casa (y algunas personas lo hacen). En ese caso, se aplica todo lo dicho anteriormente.
SELinux puede ser lo último que se interponga entre sus datos y un atacante con un exploit de 0 días que realmente lo quiere. Si usted puede usarlo, ¿por qué no?
Hay un paquete que ayuda a los usuarios a encontrar problemas causados por SELinux llamado setroubleshoot. Instálelo, configúrelo para que se ejecute al inicio. Luego, cuando obtenga una negación de SELinux, se notará en
/var/log/messages. Si también ha iniciado sesión en la GUI, recibirá una notificación.fuente