SELinux

Security-Enhanced Linux (SELinux) es un módulo de seguridad para el kernel Linux, implementado utilizando el framework del núcleo Linux Security Modules, que proporciona el mecanismo para implementar una políticas de control de acceso de tipo Control de acceso obligatorio (MAC) y control de acceso basado en roles^[1]​ (RBAC).^[2]​^[3]​ Se trata de un conjunto de modificaciones del núcleo y herramientas de usuario que pueden ser agregadas a diversas distribuciones Linux. Su arquitectura se enfoca en separar las decisiones de las aplicaciones de seguridad de las políticas de seguridad mismas y racionalizar la cantidad de software encargado de las aplicaciones de seguridad.^[4]​^[5]​ Los conceptos clave que soportan SELinux pueden ser trazados a diversos proyectos previos de la Agencia de Seguridad Nacional de Estados Unidos.

SELinux
GUI del administrador de SELinux en Fedora v8
Información general
Tipo de programa	Linux Security Module
Autor	NSA y Red Hat
Desarrollador	Red Hat
Lanzamiento inicial	22 de diciembre de 2000 (20 años, 7 meses y 13 días)
Licencia	GPL
Estado actual	En desarrollo
Información técnica
Programado en	C
Versiones
Última versión estable	2.8 24 de mayo de 2018
Enlaces
Sitio web oficial Repositorio de código
[editar datos en Wikidata]

SELinux ha sido integrado a la rama principal del núcleo Linux desde la versión 2.6, el 8 de agosto de 2003.

Las distribuciones GNU/Linux Fedora, Red Hat Enterprise Linux, CentOS y Scientific Linux incorporan SELinux habilitado por defecto.

Android incluye SELinux por primera vez en la versión 4.3 Jelly Bean, pero en modo permisivo. En Android 4.4 KitKat se incluye activado parcialmente, sólo en algunos dominios cruciales (installd, netd, vold y zygote). Desde Android 5.0 Lollipop se incorpora SELinux habilitado totalmente.

Descripción

Los sistemas basados en UNIX incorporan control de acceso discrecional (DAC), el cual corresponde a los permisos tradicionales de UNIX: Propietario, Grupo y Otros; Lectura, Escritura y Ejecución. SELinux pemite políticas de acceso control de acceso obligatorio (MAC) y control de acceso basado en roles (RBAC) en Linux.

Una aplicación supervisada por SELinux posee acceso únicamente a los recursos que necesita, los cuales están descritos en una política de seguridad para dicho proceso. El acceso a procesos, puertos, archivos y directorios está controlado mediante reglas definidas en dicha política, es decir, el módulo de seguridad del kernel (SELinux), autoriza o deniega todas las operaciones del sistema con base en unas políticas de seguridad que definen por completo qué recursos del sistema pueden acceder las aplicaciones individuales y con qué privilegios.

El objetivo de este sistema de seguridad es proteger proactivamente el sistema operativo y las aplicaciones contra amenazas externas o internas, como ataques de día cero (zero-day), mediante el cumplimiento de un buen comportamiento, y así evitar la explotación de agujeros de seguridad en software, incluso si aún son desconocidos.

Inicialmente, los sistemas de seguridad de control de acceso obligatorio, como SELinux, se utilizaban a nivel gubernamental, empresarial y en servidores web, con el objetivo de reducir el riesgo de ataques informáticos. No obstante, actualmente, todos los sistemas operativos modernos lo incorporan, como Android (SELinux),^[6]​ macOS/FreeBSD (TrustedBSD) y GNU/Linux (AppArmor, SELinux, TOMOYO, etc.).

Diferencias con AppArmor

Las distribuciones Linux incorporan MAC mediante módulos de seguridad, como SELinux y AppArmor. Cada tienen sus peculiaridades.

SELinux está orientado a proteger el sistema completo, todos los objetos del sistema (ficheros, objetos IPC, redes, ...). Sin embargo AppArmor solo está orientado al sistema de ficheros.^[7]​

AppArmor implementa una política centrada en la tarea, lo que significa que los atributos de control de acceso están vinculados a las tareas.^[7]​ Las reglas con las restricciones para cada aplicación están definidas en los llamadas perfiles de tareas. ^[7]​Estos pueden incluir habilidades para manipular ficheros específicos, usar red o montar dispositivos. ^[7]​El control de acceso está basado en rutas (de directorios, archivos, puertos,...) que se especifican. ^[7]​Programas que no tienen un perfil definido ejecutan sin restricciones por su parte (solo las restricciones del sistema de permisos UNIX).^[7]​

SELinux implementa una política centrada en los objetos del sistema. Cada 'objeto del sistema (proceso, puerto, archivo, directorio,..) se le asigna una etiqueta ( contexto de seguridad), que será utilizada por la política de seguridad para determinar el acceso a este. El contexto de seguridad incluye distintos atributos como la identidad del usuario, rol, tipo, nivel,...^[7]​

Ambos sistemas usan el principio de "denegación por defecto" (todas las operaciones son denegadas a menos que esté específicamente permitida por la política). Sin embargo, cada uno lo aplica de distinta manera:^[7]​

• AppArmor, al implementar una política centrada en la tarea, solo aplica el principio para aquellas tareas que controla.
• SELinux aplica el principio en todo caso.

En general podemos decir que SELinux facilita un control de acceso de grado más fino que AppArmor.^[8]​ Por otro lado, AppArmor es más fácil de usar que SELinux ya que la configuración es más fácil de realizar (menos extensa).^[8]​

Contextos de seguridad

En un sistema operativo con SELinux, cada objeto del sistema posee un contexto de seguridad. Este es utilizado por las políticas de seguridad para definir el acceso a estos. El contexto de seguridad se almacena en un atributo del sistema de archivos, en los inodos, por lo tanto, se requiere de un sistema de archivos con atributos extendidos.

Un contexto de seguridad posee la estructura usuario_u:rol_r:tipo_t:nivel. Este se compone por:

• Identidad o usuario: usuario de SELinux, que es diferente al usuario del sistema. Este cumple la misma función que un usuario UNIX. Generalmente, un usuario SELinux está asociado a un conjunto de usuarios UNIX. La idea es que SELinux sea un sistema de seguridad independiente al control de acceso discrecional de UNIX, por ello que se usa usuario distinto. Comúnmente, se utiliza el sufijo _u.
• Roles: rol de SELinux, si el control de acceso basado en roles está configurado. Por defecto, todos los objetos del sistema tienen rol object_r. Se suele usar el sufijo _r.
• Tipo: tipo de objeto SELinux o Type Enforcement. Determina los permisos de acceso, es decir, la política de seguridad a usar. Este atributo es utilizado por el control de acceso obligatorio. El tipo de objeto de un proceso se llama dominio. Normalmente, se usa el sufijo _t.
• Nivel: Se utiliza sólo con políticas avanzadas multi-nivel (MLS) o multi-categoría (MCS). Son extensiones que permiten un control aún más preciso mediante un etiquetado adicional con dos entidades: sensibilidad y categoría. La etiqueta sensibilidad es jerárquica, así un proceso en un determinado nivel tiene acceso de lectura a niveles inferiores pero solo puede escribir en un nivel igual o superior. La etiqueta categoría es un atributo no jerárquico. Con este tipo de política se pueden definir reglas más granulares y precisas, aunque con mayor complejidad. Es utilizada cuando se quiere aportar un estricto control, por ejemplo, en organizaciones cuya seguridad es crítica. Por defecto, con tipo de políticas targeted, el nivel es siempre s0.

Ejemplo de contextos de seguridad:

• Directorio de servidor web (inodo): system_u:object_r:httpd_sys_content_t:s0
• Directorio Home (inodo): system_u:object_r:home_user_t:s0
• Apache y NGINX (dominio): system_u:system_r:httpd_t:s0

Para ver el contexto de seguridad de archivos y carpetas, utilice la opción -Z en el comando ls:

ls -Z 

Manejo

SELinux puede permanecer en 3 estados:

• Enforcing (obediente): SELinux habilitado. Denegar todos los accesos no autorizados, según las políticas de seguridad.
• Permissive (permisivo): Permitir todos los accesos no autorizados, pero mostrar alertas sobre ellos.
• Disabled: SELinux desactivado.

SELinux incorpora dos tipos de políticas:

• Política "targeted": sólo los procesos que cuenten con una política de seguridad están bajo el control SELinux, por ejemplo, algunos procesos relevantes, como apache, nginx, dns, proxy squid, snmp y syslog. Es la política por defecto y proporciona un control bastante eficaz y de relativa sencillez. Los procesos sin una política quedan fuera del contexto de seguridad de SELinux y sobre ellos se aplica la seguridad estándar de Linux (DAC).
• Política multi-nivel/multi-categoria (MLS/MCS): habilita la seguridad multi-nivel o multi-categoría.

Políticas de seguridad

La política de seguridad usada comúnmente por las distribuciones GNU/Linux es la Política de Referencia de SELinux (refpolicy). También, existe la Política de Seguridad de Android (sepolicy).

Véase también

•   Portal:Software libre. Contenido relacionado con Software libre.
• AppArmor

Enlaces externos

• Preguntas frecuentes sobre Seguridad Mejorada de Linux Manual de Fedora Linux
• The SELinux Notebook (En Inglés)
• NSA - SELinux (En inglés)
• NSA - Preguntas Frecuentes (En inglés)

Referencias

1. SELinux/Role-based access control. wiki.gentoo.org. 13 de junio de 2015
2. LPIC-303-200 (Security). 327.2 Mandatory Access Control]. Carlos Briso. 2017
3. SElinux: arquitectura de seguridad para los sistemas Linux. redhat.com
4. «SELinux Frequently Asked Questions (FAQ) - NSA/CSS». National Security Agency. Consultado el 6 de febrero de 2013. 
5. . 18 de octubre de 2011. Consultado el 29 de septiembre de 2018. 
6. «Security-Enhanced Linux in Android». Android Open Source Project (en inglés). Consultado el 3 de febrero de 2019. 
7. A Secure Linux Desktop Environment. Zuzana Hromcová. Universidad Comenius de Bratislava. 2019
8. . insanitybit.com. 1 de junio de 2012

•   Datos: Q116038
•   Multimedia: Category:SELinux