Lograr inicio con SELinux
Introducción a SELinux
Mejora de Seguridad en Linux (SELinux) proporciona una capa adicional de seguridad del sistema. SELinux fundamentalmente responde la pregunta: Podría <sujeto> hacer <acción> a <objeto>?, por ejemplo; ¿Podría un servidor web acceder a archivos dentro del directorio inicial de usuarios?
La normativa de acceso estándar basada en usuarios, grupos y otros permisos, conocida como Control de acceso discrecional (DAC), no permite a los administradores de sistemas crear normativas de seguridad integradas y detalladas, como restringir que aplicaciones específicas solo vean archivos de bitácora y permitir que otras aplicaciones agreguen datos nuevos a los archivos de bitácora.
SELinux implementa el Control de Acceso Obligatorio (MAC). Cada proceso y recurso del sistema tiene una etiqueta de seguridad especial denominada contexto SELinux. Un contexto SELinux, a veces denominado etiqueta SELinux, es un identificador que abstrae los detalles a nivel de sistema y se centra en las propiedades de seguridad de la entidad. Esto no solo proporciona una forma consistente de referenciar objetos en la política de SELinux, sino que también elimina cualquier ambigüedad que pueda encontrarse en otros métodos de identificación; por ejemplo, un archivo puede tener varias rutas válidas en un sistema que utiliza montajes de enlace.
La normativa de SELinux utiliza estos contextos en unas series de reglas las cuales definen como los procesos pueden interactuar con cada otro y el varios recursos del sistema. Por defecto la normativa no permite ninguna interacción a no ser que una regla explícitamente concede acceso.
|
Es importante recordar que los reglamentos de normativas de SELinix están marcados tras las reglas DAC. Las reglas de normativa SELinux no son utilizados si las reglas DAC deniegan el acceso si las reglas DAC tradicionales impiden el acceso. |
Los contextos SELinux tienen varios campos: usuario, rol, tipo y nivel de seguridad. La información sobre el tipo SELinux es quizás la más importante en lo que respecta a la política SELinux, ya que la regla de política más común que define las interacciones permitidas entre los procesos y los recursos del sistema utiliza los tipos SELinux y no el contexto SELinux completo. Los tipos SELinux suelen terminar en _t. Por ejemplo, el nombre del tipo para el servidor web es httpd_t. El contexto de tipo para los archivos y directorios que se encuentran normalmente en /var/www/html/ es httpd_sys_content_t. Los contextos de tipo para los archivos y directorios que se encuentran normalmente en /tmp y /var/tmp/ son tmp_t. El contexto de tipo para los puertos del servidor web es http_port_t.
Por ejemplo, existe una regla de política que permite a Apache (el proceso del servidor web que se ejecuta como httpd_t) acceder a archivos y directorios con un contexto que normalmente se encuentra en /var/www/html/ y otros directorios del servidor web (httpd_sys_content_t). No hay ninguna regla de permiso en la política para los archivos que se encuentran normalmente en /tmp y /var/tmp/, por lo que no se permite el acceso. Con SELinux, incluso si Apache se ve comprometido y un script malicioso obtiene acceso, sigue sin poder acceder al directorio /tmp.
Recursos adicionales
Para mejor entendimiento de conceptos básicos de SELinux, consulte la documentación a continuación:
Beneficios de ejecutar SELinux
SELinux proporciona los siguientes beneficios:
-
Todos los procesos y archivos están etiquetados. Las reglas de normativa SELinux definen como interactúan los procesos con los archivos, así como interactúan los procesos entre sí. Sólo está permitido el acceso si existe una regla de política SELinux que lo permite específicamente.
-
Control de acceso granular. Yendo más allá de los permisos UNIX tradicionales que se controlan a discreción del usuario y en base a las ID de usuario y grupo de Linux, las decisiones de acceso de SELinux se basan en toda la información disponible, tales como usuario SELinux, rol, tipo y opcionalmente, un nivel de seguridad.
-
La normativa SELinux está definida administrativamente y fuerza a todo el sistema.
-
Mitigación mejorada de ataques de escalada de privilegios. Los procesos se ejecutan en dominios y, por lo tanto, están separados entre sí. Las reglas de normativa de SELinux definen cómo los procesos acceden a los archivos y a otros procesos. Si un proceso se ve comprometido, el atacante solo tiene acceso a sus funciones habituales y a los archivos configurados para ello. Por ejemplo, si el servidor HTTP Apache se ve comprometido, un atacante no puede usar ese proceso para leer archivos en los directorios personales de los usuarios, a menos que se haya añadido o configurado una regla de normativa de SELinux específica para permitir dicho acceso.
-
SELinux se puede utilizar para garantizar la confidencialidad e integridad de los datos, así como para proteger los procesos frente a entradas no fiables.
Sin embargo, SELinux no es:
-
software antivirus,
-
sustitución por contraseñas, cortafuegos, y otros sistemas de seguridad,
-
solución de seguridad todo-en-uno.
SELinux está diseñado para mejorar soluciones de seguridad existentes, no las reemplaza. Incluso cuando ejecute SELinux, es importante continuar para seguir las prácticas de seguridad, tales como conservar el software al día, utilizar contraseñas difíciles de adivinar, o cortafuegos.
Ejemplos de SELinux
Los ejemplos siguientes demuestran como SELinux incremente seguridad:
-
La acción por defecto es denegar. Si una regla de normativa SELinux no existe para permitir acceso, tal como para un proceso abriendo un archivo, el acceso es denegado.
-
SELinux puede restringir usuarios de Linux. La normativa de SELinux incluye varios usuarios restringidos de SELinux. Es posible asignar usuarios de Linux a usuarios restringidos de SELinux para aprovechar las reglas y mecanismos de seguridad que se les aplican. Por ejemplo, asignar un usuario de Linux al usuario
user_ude SELinux impide que un usuario de Linux ejecute (a menos que se configure de otra manera) aplicaciones con ID de usuario definido (setuid), comosudoysu, además de impedirle ejecutar archivos y aplicaciones en su directorio personal. Si se configura, esto impide que los usuarios ejecuten archivos maliciosos desde sus directorios personales. -
Proceso y separación de datos incrementados. Los procesos ejecutan en sus propio dominios, permitiendo procesos desde archivos accedidos utilizados por otros procesos, así como prevenir procesos desde acceso a otros procesos. Por ejemplo, cuando ejecuten SELinux, a no ser que en otro caso configuren, un adjunto no puede comprometer un servidor Samba, y entonces utiliza ese servidor Samba como un vector de ataque para leer y escribir a archivos utilizados por otros procesos., tales como bases de datos MariaDB.
-
SELinux ayuda a mitigar el daño causado por errores de configuración. Los servidores del Sistema de Nombres de Dominio (DNS) suelen replicar información entre sí mediante una transferencia de zona. Los atacantes pueden usar estas transferencias para actualizar los servidores DNS con información falsa. Al ejecutar el Dominio de Nombres de Internet de Berkeley (BIND) como servidor DNS en Fedora, incluso si un administrador olvida limitar qué servidores pueden realizar una transferencia de zona, la política predeterminada de SELinux impide que los archivos de zona se actualicen mediante transferencias de zona, por el propio demonio BIND
namedy por otros procesos. -
Consulte el artículo NetworkWorld.com, Un cinturón de seguridad para el software de servidor: SELinux bloquea los exploits del mundo real[1], para obtener información general sobre SELinux e información sobre diversos exploits que SELinux ha impedido.
Arquitectura SELinux
SELinux es un Módulo de Seguridad de Linux (LSM) integrado en el kernel de Linux. El subsistema SELinux del kernel se rige por una normativa de seguridad controlada por el administrador y cargada al arrancar. SELinux intercepta todas las operaciones de acceso a nivel de kernel relevantes para la seguridad del sistema y las examina en el contexto de la normativa de seguridad cargada. Si la normativa cargada permite la operación, esta continúa. De lo contrario, se bloquea y el proceso recibe un error.
Decisiones de SELinux, tales como permitir o impedir acceso, son cacheadas. Esta caché es conocida como el AVC (Access Vector Cache). Cuando utiliza decisiones cacheadas, las reglas de normativa de SELinux necesitan ser marcadas menos, lo cual incrementa rendimiento. Recuerde que la normativa de SELinux no tiene efecto si las reglas DAC deniegan primero el acceso.
Estados y modos de SELinux
SELinux puede ejecutar en uno de tres modos: deshabilitado, permisivo, o forzado.
Se desaconseja enfáticamente el modo deshabilitado; el sistema no solo evita aplicar la política de SELinux, sino que también evita etiquetar cualquier objeto persistente como archivos, lo que dificulta la habilitación de SELinux en el futuro.
En modo permisivo, el sistema actúa como si SELinux aplicara la política de seguridad cargada, lo que incluye etiquetar objetos y emitir entradas de denegación de acceso en los registros, pero no deniega ninguna operación. Aunque no se recomienda para sistemas de producción, el modo permisivo puede ser útil para el desarrollo de políticas de SELinux.
Modo reforzado es el predeterminado, y recomendado, modo de operación; en modo reforzado de SELinux opera normalmente, reforzando la normativa de seguridad cargada en el sistema entero.
Emplee la utilidad setenforce para cambiar entre modo reforzado y permisivo. Los cambios hechos con setenforce no persiste a través de reinicios. Para cambiar a modo reforzado, introduzca el comando `setenforce 1 como el usuario root de Linux. Para cambiar al modo permisivo, introduzca el comando setenforce 0. Utilice la utilidad getenforce para ver el modo SELinux actual:
[~]# getenforce Enforcing
[~]# setenforce 0 [~]# getenforce Permissive
[~]# setenforce 1 [~]# getenforce Enforcing
En Fedora, puede establecer dominios individuales para modo permisivo mientras el sistema ejecute en modo reforzado. Por ejemplo, para hacer el dominio httpd_t permisivo:
[~]# semanage permissive -a httpd_t
Want to help? Learn how to contribute to Fedora Docs ›