SELinux

De Departamento de Informatica
Saltar a: navegación, buscar

Contenido

Qué es SELinux

Logo de SELinux

SELinux (Security-Enhanced Linux) es un módulo de seguridad para el kernel Linux (LSM, Linux Security Module) que provee Control de Acceso Obligatorio (MAC, Mandatory Access Control). El objetivo de SELinux y del MAC es proteger proactivamente el sistema operativo y las aplicaciones contra amenazas externas o internas, como ataques de zero-day, mediante el cumplimiento de un buen comportamiento, y evitar la explotación de fallas de seguridad en software, incluso si aún son desconocidas.

Los sistemas basados en UNIX incorporan Control de Acceso Direccional (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) y Control de Acceso Basado en Roles (RBAC) en Linux. En el MAC, cada proceso, puerto, usuario, archivo y directorio posee una política de seguridad asociada que le proporciona los privilegios mínimos para su funcionamiento. En palabras simples, cada aplicación del sistema se ejecuta en un "sandbox" (caja de arena), en donde posee acceso únicamente a los recursos que necesita. 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.

Un ejemplo práctico de la implementación del MAC, es la gestión de permisos de Android y iOS, en donde el usuario puede definir una política de seguridad (como el acceso a cámara, micrófono, contactos, calendario, GPS, etc.) para cada aplicación individual. En Android se utiliza SELinux (Linux) y en iOS se usa TrustedBSD (FreeBSD).

El MAC fue diseñado, inicialmente, para utilizarse a nivel gubernamental, empresarial y en servidores, con el objetivo de aumentar la seguridad de los sistemas, debido a los riesgos de ataques informáticos. No obstante, actualmente, todos los sistemas operativos modernos lo incorporan, como Windows, macOS/iOS, Android y GNU/Linux.

SELinux fue desarrollado en lenguaje C por RedHat y la NSA (Agencia de Seguridad de EE.UU.), con el fin de utilizarse en los sistemas de defensa de EE.UU. Actualmente es mantenido por RedHat. La primera versión fue publicada el 22 de diciembre de 2000 bajo una licencia GPL. Fue añadido a la rama principal de Linux, en la versión 2.6.0-test3, publicada el 8 de agosto de 2003.

Sitio (Wiki) oficial de SELinux: selinuxproject.org
Repositorio oficial de SELinux: github.com/SELinuxProject


Mecanismos de Control de Acceso

Control de Acceso Direccional (DAC) y Control de Acceso Obligatorio (MAC)

Todos los sistemas operativos modernos incorporan mecanismos para el control de acceso. Generalmente, un sistema operativo utiliza varios de éstos.

Control de Acceso Direccional (DAC)

El acceso a objetos se restringe según el grupo al cual pertenecen. Los sistemas basados en UNIX, como GNU/Linux y macOS, lo incorporan, mediante los permisos de acceso: Propietario, Grupo y Otros; Lectura, Escritura y Ejecución. Microsoft lo implementa en Windows 2000.

Control de Acceso Obligatorio (MAC)

Se basa en el principio del privilegio mínimo. Las aplicaciones se ejecutan en un "sandbox", en donde sólo poseen acceso a los recursos que necesitan. En otras palabras, cada objeto (procesos, puertos, archivos, carpetas) posee permisos de acceso y privilegios exclusivos, definidos por una política de seguridad.

Pueden establecerse dos tipos de control de acceso obligatorio:

  • MAC basado en etiquetas: Cada objeto posee un "contexto de seguridad" que determina la política de acceso a usar, mediante un atributo en el sistema de archivos, es decir, en los inodos. Ejemplo: SELinux (módulo de seguridad de Linux).
  • MAC basado en nombres de rutas: No se usa el sistema de archivos. Existe un índice que asocia las rutas de directorios y archivos, puertos y procesos a un "contexto de seguridad", que determina la política de acceso. Ejemplo: AppArmor (módulo de seguridad de Linux).

Las distribuciones GNU/Linux incorporan MAC mediante módulos de seguridad, como SELinux y AppArmor. Android integra MAC en la versión Lollipop (5.0), mediante SELinux (Android KitKat incluye SELinux activado parcialmente, sólo en procesos cruciales). macOS (también iOS) lo incorpora, desde la versión Lion (10.7), mediante el módulo de seguridad para sistemas FreeBSD, TrustedBSD.

Control de Acceso Basado en Roles (RBAC)

Los permisos se otorgan según los roles que otorga el sistema de seguridad.

Control de Integridad Obligatorio (MIC)

Mecanismo de control de acceso diseñado por Microsoft para Windows. Los permisos se otorgan según un nivel de seguridad (existen 4 niveles de seguridad) y según un descriptor de seguridad en objetos. Incorporado desde Windows Vista.


Comenzando con SELinux

Requisitos para el uso de SELinux

La ejecución de SELinux en una distribución GNU/Linux requiere de 3 cosas:

  1. Un kernel con SELinux habilitado.
  2. Las herramientas de espacio de usuario de SELinux (como las herramientas para construir y compilar módulos de políticas de seguridad).
  3. Las políticas de SELinux (en base a una política de referencia).

También se tendrán que parchear o recompilar con las características de SELinux algunos paquetes comunes de GNU/Linux, como systemd, sudo, openssh, dbus, cronie, iproute, pam, coreutils, etc.

SELinux requiere de un sistema de archivos con atributos extensibles, como ext2, ext3, ext4, JFS, XFS y BtrFS.

Sistemas operativos con SELinux habilitado por defecto

GNU/Linux:

  • Fedora
  • Red Hat Enterprise Linux
  • CentOS
  • Scientific Linux

Android:

  • Android 5.0 Lollipop y superiores.
  • CyanogenMod 10.1+
  • Samsung KNOX (Android 4.3+)

Google incorpora SELinux en Android 4.3, pero en modo permissive. En Android 4.4 se incluye modo enforcing parcial, es decir, sólo algunos dominios cruciales se ejecutan en modo enforcing (installdnetdvold y zygote). Luego, en Android 5.0 se cambia modo enforcing total.

SE for Android: https://seandroid.bitbucket.org

Sistemas operativos con SELinux disponible, pero deshabilitado

Distribuciones GNU/Linux con SELinux implementado en el kernel, pero deshabilitado por defecto:


Funcionamiento de SELinux

Políticas de Seguridad

Políticas y Módulo de Seguridad.

Las políticas de seguridad son una serie de reglas para autorizar y denegar operaciones.

El módulo de seguridad del kernel (SELinux), valida o invalida operaciones en base a políticas de seguridad predefinidas. Cada proceso posee una política de seguridad asociada, que puede ser exclusiva para aquél o heredada del proceso que lo invocó.

Contextos de Seguridad

El contexto de seguridad determina qué política de acceso se debe utilizar en objetos (procesos, ficheros, directorios, puertos, etc.), es decir, limita el acceso que las aplicaciones tienen a los recursos del sistema.

Cada objeto posee un contexto de seguridad. Éste está definido por la identidad de usuario SELinux, el rol, el tipo de objeto. SELinux usa MAC basado en etiquetas, por lo tanto, usa atributos extendidos en el sistema de archivos para albergar el contexto de seguridad.

Contexto de seguridad:

  • Identidad o usuario [_u]: Usuario de SELinux, diferente al usuario del sistema. Determina cuál es la política de seguridad de referencia.
  • Roles [_r]: Controla las transiciones o cambios de tipos.
  • Tipo [_t]: Determina los permisos de acceso, es decir, la política de seguridad a usar. El tipo de un proceso se llama dominio.
  • Nivel: Se utiliza sólo con políticas avanzadas MLS/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 nivel igual o superior. La etiqueta categoría es un atributo no jerárquico. Con este tipo de política se pueden definen reglas más granulares y precisas, aunque la complejidad aumenta. 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 (proceso): system_u:system_r:httpd_t:s0

Los procesos heredan el dominio del proceso que lo invoca y la identidad del usuario que lo ejecuta. Luego, SELinux cambia automáticamente el dominio del proceso según las políticas de seguridad, de modo de otorgar permisos exclusivos.


Contextos de Seguridad y Usuarios UNIX. Transiciones entre Dominios.

Manejo de SELinux

Habilitar o Deshabilitar SELinux

SELinux se puede habilitar o deshabilitar en el archivo de configuración:

/etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted

Para aplicar cambios, es necesario reiniciar el sistema.

Se definen 3 modos o estados de SELinux:

  • 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 una serie de procesos escogidos del sistema están bajo el control SELinux, 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. El resto de procesos quedan fuera del contexto de seguridad de SELinux y sobre ellos se aplica la seguridad estándar de Linux (DAC).
  • Política Multinivel/Multicategoria (MLS/MCS): Es una aplicación avanzada de SELinux de una mayor complejidad. Es utilizada cuando se quiere aportar un estricto control por ejemplo, en organizaciones cuya seguridad es crítica.

Comandos Básicos

Estado de SELinux:

Ver estado de SELinux:

$ sestatus

Activar SELinux en modo enforcing, sin reiniciar el sistema:

$ sudo setenforce 1

Modo permissive, sin reiniciar el sistema:

$ sudo setenforce 0

Políticas de seguridad:

Listar todos los módulos de políticas se seguridad:

$ sudo semodule -l

Añadir módulo de políticas de seguridad:

$ sudo semodule -i archivo_de_políticas.pp

Nota: Borrar módulo de políticas con -d

Contextos de seguridad:

Ver contexto de seguridad de archivos/carpetas:

$ ls -Z

Modificar contexto de seguridad de archivo/carpeta:

$ chcon <opciones> <ruta>


Booleanos

Los booleanos son ajustes que controlan los permisos de ejecución de una serie de aplicaciones predefinidas.

Ver booleanos que se encuentran activos o inactivos:

$ getsebool -a

Activar un booleano especificado:

$ setsebool [1|0] [booleano]

Activar permanente un booleano especificado:

$ setsebool -P [booleano] 1

Booleanos: https://wiki.centos.org/TipsAndTricks/SelinuxBooleans


Log de SELinux

Archivo de Log:

/var/log/audit/audit.log

Los mensajes de SELinux poseen el tipo AVC.

Ejemplo de mensaje de SELinux, en donde se bloquea la conexión de NGINX por el puerto 8001:

type=AVC msg=audit(1475163445.167:475): avc:  denied  { name_connect } 
for  pid=2865 comm="nginx" dest=8001 scontext=system_u:system_r:httpd_t:s0 
tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0


Configuración de SELinux

Apache y NGINX

A modo de ejemplo, tenemos un servidor con NGINX, en Fedora 24, conectado por el puerto 80 y a Django mediante el puerto 8001. Tanto Apache como NGINX poseen el mismo contexto de seguridad, por lo tanto, la configuración es la misma:

  • Usuario SELinux: system_u
  • Rol: system_r
  • Dominio (tipo de objeto): httpd_t

La política se seguridad asociada al dominio httpd_t concede el acceso a la red mediante el puerto 80, pero bloquea el puerto 8001. Esto sucede, porque los procesos con dominio httpd_t sólo pueden conectarse a través de puertos que tengan el tipo de objeto http_port_t.

NGINX y SELinux


Solución para SELinux en Modo Enforcing

Opción 1: Permitir a Apache y NGINX conectarse por un puerto específico

Como Apache y NGINX tienen dominio httpd_t, sólo pueden conectarse a través de puertos que posean el tipo de objeto SELinux http_port_t. Por defecto, el puerto 80 tiene el tipo http_port_t, pero el puerto 8001 no. Por lo tanto, se le debe asignar el tipo de objeto http_port_t a cualquier puerto con el que se conecte Apache o NGINX.

Permitir conectar a Apache/NGINX por el puerto 8001:

$ sudo semanage port -a -t http_port_t -p tcp 8001

-a: agregar, -t: tipo de objeto SELinux, -p: protocolo

Nota: Quitar tipo de objeto con -d.

Opción 2: Permitir que Apache y NGIX puedan conectarse a la red por cualquier puerto

Permite que servicios HTTPD (servidores HTTP), puedan conectarse a la red por cualquier puerto, cambiando a true el booleano httpd_can_network_connect.

$ sudo setsebool -P httpd_can_network_connect 1

Tipo de objeto del directorio de la aplicación o página Web

Los procesos con dominio httpd_t (como Apache y NGINX) sólo pueden acceder a directorios y archivos que posean el tipo de objeto httpd_sys_content_t. Por ende, los directorios que alberguen el proyecto de la aplicación Web o cualquier página estática, deben poseer el tipo httpd_sys_content_t.

Nótese que en el ejemplo anterior, el servicio que accede al proyecto Django es uWSGI, no NGINX; por lo tanto, en aquel caso, no es indispensable este procedimiento.

Para ver el contexto de seguridad de archivos y carpetas, usamos el comando:

$ ls -Z

Cambiar al tipo httpd_sys_content_t el directorio en donde se almacena la aplicación o página Web:

$ sudo chcon -Rt httpd_sys_content_t <directorio-web>

-t: Tipo de objeto SELinux, -R: Aplicar en forma recursiva


Bases de Datos

PostgreSQL

El proceso de PostgreSQL posee el dominio postgresql_t, por lo tanto, sólo puede conectarse a puertos que posean el tipo de objeto postgresql_port_t y sólo puede acceder a directorios y archivos con el tipo postgresql_db_t.

PostgreSQL y SELinux

Permitir a PostgreSQL conectarse mediante el puerto 5433 (asignar tipo postgresql_port_t):

$ sudo semanage port -a -t postgresql_port_t -p tcp 5433

-a: agregar, -t: tipo de objeto SELinux, -p: protocolo

Nota: Quitar tipo de objeto con -d.


Si se modifica el directorio de la base de datos, otorgarle el tipo postgresql_db_t a éste:

$ semanage fcontext -a -t postgresql_db_t "/my/new_location(/.*)?"

Nota: (/.*)? indica que los cambios se aplican recursivamente en el directorio.

SELinux y PostgreSQL:

MariaDB/MySQL

El proceso de MariaDB o MySQL posee el dominio mysqld_t, por lo tanto, sólo puede conectarse mediante puertos que tengan el tipo de objeto SELinux mysqld_port_t y sólo puede acceder a directorios y archivos con el tipo mysqld_db_t.

Permitir a MariaDB/MySQL conectarse mediante el puerto 3307 (asignar tipo mysqld_port_t):

$ sudo semanage port -a -t mysqld_port_t -p tcp 3307

-a: agregar, -t: tipo de objeto SELinux, -p: protocolo

Nota: Quitar tipo de objeto con -d.


Si se modifica el directorio de la base de datos, otorgarle el tipo mysqld_db_t a éste:

$ sudo semanage fcontext -a -t mysqld_db_t "/my/new_location(/.*)?"

Nota: (/.*)? indica que los cambios se aplican recursivamente en el directorio.

SELinux y MariaDB/MySQL: https://mariadb.com/kb/en/mariadb/what-to-do-if-mariadb-doesnt-start/#selinux


Permitir a una base de datos conectarse a Aplicaciones Web vía TCP/IP, si la Aplicación Web y la base de datos están en servidores distintos:

$ sudo setsebool -P httpd_can_network_connect_db on


Alternativas a SELinux

AppArmor

AppArmor es un módulo de seguridad de Linux (LSM) que proporciona mecanismos de control de acceso obligatorio (MAC). Fue desarrollado inicialmente por Immunix, empresa posteriormente adquirida por Novell, quien continuó su desarrollo. Actualmente es mantenido por Canonical.

A muchos administradores de sistemas no les gusta SELinux debido a su alta complejidad. AppArmor fue creado como una alternativa a SELinux más fácil de configurar y mantener. Usa el mismo framework que SELinux, por lo que ambos son intercambiables.

La diferencia más apreciable con SELinux es que AppArmor no usa atributos extendidos en el sistema de archivos y usa políticas de seguridad en texto plano.

Algunas distribuciones GNU/Linux que lo usan:

  • OpenSUSE y SUSE
  • Ubuntu
  • Kali Linux
  • Distribuciones basadas en Ubuntu, como Linux Mint, elementaryOS, KDE Neon, etc.

Sitio web: http://wiki.apparmor.net

GRSecurity

GRSecurity es otro módulo de seguridad de Linux (LSM), pero que provee Control de Acceso Basado en Roles (RBAC). Es más sencillo de configurar y mantener que SELinux y AppArmor. Puede ejecutarse de manera simultánea con SELinux.

Sitio web: https://grsecurity.net

TOMOYO Linux y AKARI

TOMOYO Linux es un módulo de seguridad de Linux (LSM) que provee Control de Acceso Obligatorio. Fue lanzado el 2003 por la empresa japonesa NTT Data Corporation y su desarrollo fue descontinuado en 2012. AKARI es un fork de TOMOYO Linux, creado por la misma compañía, que añade nuevas características.

Sitio Web de TOMOYO Linux: http://tomoyo.osdn.jp

Sitio Web de AKARI: http://akari.osdn.jp

Smack

Smack (Simplified Mandatory Access Control Kernel) es un módulo de seguridad de Linux (LSM) basado en SELinux y diseñado para proveer un control de acceso obligatorio simplificado para el sistema operativo móvil MeeGo (MeeGo fue descontinuado en favor de Tizen, pero existe un fork de MeeGo llamado Mer, con distribuciones basadas en éste, como Sailfish OS).

Sitio web: http://schaufler-ca.com


Referencias

Herramientas personales
Espacios de nombres
Variantes
Acciones
Navegación
Herramientas