SELinux

De Wikipedia, la enciclopedia libre
Ir a la navegación Ir a la búsqueda
SELinux
selinuxproject.org, github.com/SELinuxProject
Logotipo de SELinux
SELinux admin.png
GUI del administrador de SELinux en Fedora v8
Información general
Desarrollador(es) Red Hat
Autor(es) NSA y Red Hat
Lanzamiento inicial 22 de diciembre de 2000 (18 años, 11 meses y 15 días)(info)
Última versión estable 2.9 (info)
15 de marzo de 2019 (8 meses y 22 días)
Género Seguridad, Módulos de Seguridad del kernel Linux (LSM)
Programado en C
Sistema operativo Linux
Licencia GPL
Estado actual En desarrollo

Security-Enhanced Linux (SELinux) es un módulo de seguridad para el kernel Linux que proporciona el mecanismo para soportar políticas de seguridad para el control de acceso, incluyendo controles de acceso obligatorios como los del Departamento de Defensa de Estados Unidos. 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.[1][2]​ Los conceptos clave que soportan SELinux pueden ser trazados a diversos proyectos previos de la Agencia de Seguridad Nacional de Estados Unidos.

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.

Controles de acceso[editar]

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 añade mecanismos de control de acceso obligatorio (MAC) (también llamado Type Enforcement), control de acceso basado en roles (RBAC) y seguridad multi-nivel (MLS) y multi-categoría (MCS) 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 en base a 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)[3]​, macOS/FreeBSD (TrustedBSD) y GNU/Linux (AppArmor, SELinux, TOMOYO, etc.).

Control de acceso obligatorio[editar]

La base del control de acceso obligatorio (MAC) es el principio del privilegio mínimo, es decir, los procesos sólo tienen acceso a los recursos que necesitan. Las distribuciones Linux incorporan MAC mediante módulos de seguridad, como SELinux y AppArmor.

Pueden establecerse dos tipos de control de acceso obligatorio:

  • MAC basado en etiquetas: cada objeto del sistema (proceso, puerto, archivo o directorio) posee una "etiqueta" (contexto de seguridad), la cual es utilizada por la política de seguridad para determinar el acceso a éste. Esta "etiqueta" corresponde a un atributo en el sistema de archivos, es decir, en los inodos. Ejemplo: SELinux.
  • MAC basado en nombres de rutas: no se usa el sistema de archivos. Las reglas de acceso se asocian a las rutas de directorios, archivos y puertos. Ejemplo: AppArmor.

Contextos de seguridad[editar]

En un sistema operativo con SELinux, cada objeto del sistema posee un contexto de seguridad. Éste 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. Éste se compone por:

  • Identidad o usuario: usuario de SELinux, que es diferente al usuario del sistema. Éste 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 sólo 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[editar]

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-categoria.

Políticas de seguridad[editar]

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[editar]

Enlaces externos[editar]

Referencias[editar]

  1. «SELinux Frequently Asked Questions (FAQ) - NSA/CSS». National Security Agency. Consultado el 6 de febrero de 2013. 
  2. «Integrating Flexible Support for Security Policies into the Linux Operating System». 18 de octubre de 2011. Consultado el 29 de septiembre de 2018. 
  3. «Security-Enhanced Linux in Android». Android Open Source Project (en inglés). Consultado el 3 de febrero de 2019.