Lograr inicio con SELinux

El Equipo Documental de Fedora, Peter Boy (pboy) Versión F35-F38 Last review: 2023-09-08

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.

It is important to remember that SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first, which means that no SELinux denial is logged if the traditional DAC rules prevent the access.

SELinux contexts have several fields: user, role, type, and security level. The SELinux type information is perhaps the most important when it comes to the SELinux policy, as the most common policy rule which defines the allowed interactions between processes and system resources uses SELinux types and not the full SELinux context. SELinux types usually end with _t. For example, the type name for the web server is httpd_t. The type context for files and directories normally found in /var/www/html/ is httpd_sys_content_t. The type contexts for files and directories normally found in /tmp and /var/tmp/ is tmp_t. The type context for web server ports is http_port_t.

For example, there is a policy rule that permits Apache (the web server process running as httpd_t) to access files and directories with a context normally found in /var/www/html/ and other web server directories (httpd_sys_content_t). There is no allow rule in the policy for files normally found in /tmp and /var/tmp/, so access is not permitted. With SELinux, even if Apache is compromised, and a malicious script gains access, it is still not able to access the /tmp directory.

SELinux_Apache_MariaDB_example
Figura 1. SELinux allows the Apache process running as httpd_t to access the /var/www/html/ directory and it denies the same process to access the /data/mysql/ directory because there is no allow rule for the httpd_t and mysqld_db_t type contexts). On the other hand, the MariaDB process running as mysqld_t is able to access the /data/mysql/ directory and SELinux also correctly denies the process with the mysqld_t type to access the /var/www/html/ directory labeled as httpd_sys_content_t.

Recursos adicionales

To better understand SELinux basic concepts, see the following documentation:

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.

  • SELinux policy is administratively-defined and enforced system-wide.

  • Improved mitigation for privilege escalation attacks. Processes run in domains, and are therefore separated from each other. SELinux policy rules define how processes access files and other processes. If a process is compromised, the attacker only has access to the normal functions of that process, and to files the process has been configured to have access to. For example, if the Apache HTTP Server is compromised, an attacker cannot use that process to read files in user home directories, unless a specific SELinux policy rule was added or configured to allow such access.

  • SELinux can be used to enforce data confidentiality and integrity, as well as protecting processes from untrusted inputs.

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_u de SELinux impide que un usuario de Linux ejecute (a menos que se configure de otra manera) aplicaciones con ID de usuario definido (setuid), como sudo y su, 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.

  • Increased process and data separation. Processes run in their own domains, preventing processes from accessing files used by other processes, as well as preventing processes from accessing other processes. For example, when running SELinux, unless otherwise configured, an attacker cannot compromise a Samba server, and then use that Samba server as an attack vector to read and write to files used by other processes, such as MariaDB databases.

  • SELinux helps mitigate the damage made by configuration mistakes. Domain Name System (DNS) servers often replicate information between each other in what is known as a zone transfer. Attackers can use zone transfers to update DNS servers with false information. When running the Berkeley Internet Name Domain (BIND) as a DNS server in Fedora, even if an administrator forgets to limit which servers can perform a zone transfer, the default SELinux policy prevents zone files [1] from being updated using zone transfers, by the BIND named daemon itself, and by other processes.

  • See the NetworkWorld.com article, A seatbelt for server software: SELinux blocks real-world exploits[2], for background information about SELinux, and information about various exploits that SELinux has prevented.

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.

Use the setenforce utility to change between enforcing and permissive mode. Changes made with setenforce do not persist across reboots. To change to enforcing mode, enter the setenforce 1 command as the Linux root user. To change to permissive mode, enter the setenforce 0 command. Use the getenforce utility to view the current SELinux mode:

[~]# getenforce
Enforcing
[~]# setenforce 0
[~]# getenforce
Permissive
[~]# setenforce 1
[~]# getenforce
Enforcing

In Fedora, you can set individual domains to permissive mode while the system runs in enforcing mode. For example, to make the httpd_t domain permissive:

[~]# semanage permissive -a httpd_t

1. Text files that include information, such as host name to IP address mappings, that are used by DNS servers.
2. Marti, Don. "A seatbelt for server software: SELinux blocks real-world exploits". Published 24 February 2008. Accessed 27 August 2009: https://www.networkworld.com/article/2283723/lan-wan/a-seatbelt-for-server-software--selinux-blocks-real-world-exploits.html.