SELinux

Security-Enhanced Linux ( SELinux ) es un módulo de seguridad del kernel de Linux que proporciona un mecanismo para admitir políticas de seguridad de control de acceso , incluidos los controles de acceso obligatorios (MAC).

SELinux es un conjunto de modificaciones del núcleo y herramientas de espacio de usuario que se han añadido a varias distribuciones de Linux . Su arquitectura busca separar la aplicación de las decisiones de seguridad de la política de seguridad y simplifica la cantidad de software involucrado en la aplicación de dicha política. ^{[ 3 ] [ 4 ]} Los conceptos clave subyacentes a SELinux se remontan a varios proyectos anteriores de la Agencia de Seguridad Nacional (NSA) de los Estados Unidos .

El equipo de Linux mejorado por seguridad de la NSA describe NSA SELinux como ^{[ 5 ]}

Conjunto de parches para el kernel y las utilidades de Linux que proporcionan una arquitectura de control de acceso obligatorio (MAC) robusta, flexible y eficaz en los principales subsistemas del kernel. Ofrece un mecanismo mejorado para garantizar la separación de la información según los requisitos de confidencialidad e integridad, lo que permite abordar las amenazas de manipulación y elusión de los mecanismos de seguridad de las aplicaciones, y limitar los daños que puedan causar aplicaciones maliciosas o con fallos. Incluye un conjunto de archivos de configuración de políticas de seguridad de ejemplo diseñados para cumplir objetivos de seguridad comunes y generales.

Un kernel de Linux que integra SELinux impone políticas de control de acceso obligatorias que restringen los programas de usuario y los servicios del sistema, así como el acceso a archivos y recursos de red. Limitar los privilegios al mínimo necesario para el funcionamiento reduce o elimina la capacidad de estos programas y demonios para causar daños en caso de fallos o vulnerabilidades (por ejemplo, mediante desbordamientos de búfer o configuraciones incorrectas). Este mecanismo de restricción opera independientemente de los mecanismos de control de acceso tradicionales ( discrecionales ) de Linux. No contempla el concepto de superusuario "root" y no comparte las deficiencias conocidas de los mecanismos de seguridad tradicionales de Linux, como la dependencia de binarios setuid / setgid .

La seguridad de un sistema Linux "sin modificar" (un sistema sin SELinux) depende de la corrección del núcleo, de todas las aplicaciones con privilegios y de la configuración de cada una de ellas. Un fallo en cualquiera de estas áreas puede comprometer la seguridad de todo el sistema. En cambio, la seguridad de un sistema "modificado" (basado en un núcleo SELinux) depende principalmente de la corrección del núcleo y de la configuración de su política de seguridad. Si bien los problemas con la corrección o la configuración de las aplicaciones pueden comprometer parcialmente la seguridad de programas de usuario y demonios del sistema, no necesariamente representan una amenaza para la seguridad de otros programas de usuario y demonios del sistema, ni para la seguridad del sistema en su conjunto.

Desde una perspectiva purista, SELinux ofrece una combinación de conceptos y capacidades provenientes de controles de acceso obligatorios, controles de integridad obligatorios , control de acceso basado en roles (RBAC) y arquitectura de aplicación de tipos . Las herramientas de terceros permiten crear diversas políticas de seguridad.

Los primeros trabajos dirigidos a estandarizar un enfoque que proporcionara controles de acceso obligatorios y discrecionales (MAC y DAC) dentro de un entorno informático UNIX (más precisamente, POSIX) se pueden atribuir al Grupo de Trabajo Trusted UNIX (TRUSIX) de la Agencia de Seguridad Nacional , que se reunió de 1987 a 1991 y publicó un Libro Arcoíris (#020A), y produjo un modelo formal y un prototipo de evidencia de evaluación asociada (#020B) que finalmente no se publicó.

SELinux se diseñó para demostrar a la comunidad Linux el valor de los controles de acceso obligatorios y cómo se podían añadir dichos controles a Linux. Originalmente, los parches que componen SELinux debían aplicarse explícitamente al código fuente del kernel de Linux; SELinux se integró en la rama principal del kernel de Linux en la serie 2.6.

La NSA, desarrolladora principal original de SELinux, publicó la primera versión para la comunidad de desarrollo de código abierto bajo la licencia GNU GPL el 22 de diciembre de 2000. ^{[ 6 ]} El software se integró en el kernel principal de Linux 2.6.0-test3, publicado el 8 de agosto de 2003. Otros colaboradores importantes incluyen a Red Hat , Network Associates , Secure Computing Corporation , Tresys Technology y Trusted Computer Solutions. Se han puesto a disposición versiones experimentales de la implementación FLASK /TE a través del proyecto TrustedBSD para los sistemas operativos FreeBSD y Darwin .

Security-Enhanced Linux implementa el núcleo de seguridad avanzada Flux (FLASK) ^{[ 7 ]} . Este núcleo contiene componentes arquitectónicos prototipados en el sistema operativo Fluke ^{[ 8 ]} . Estos proporcionan soporte general para la aplicación de diversos tipos de políticas de control de acceso obligatorio ^{[ 9 ]} , incluidas aquellas basadas en los conceptos de aplicación de tipos , control de acceso basado en roles y seguridad multinivel . FLASK, a su vez, se basó en DTOS, un sistema operativo distribuido y confiable derivado de Mach, desarrollado como parte de una investigación previa sobre sistemas de control de acceso obligatorio ^{[ 10 ]} .

Los usuarios y roles de SELinux no tienen por qué estar relacionados con los usuarios y roles reales del sistema. Para cada usuario o proceso actual, SELinux asigna un contexto de tres cadenas compuesto por un nombre de usuario, un rol y un dominio (o tipo). Este sistema es más flexible de lo habitual: por lo general, la mayoría de los usuarios reales comparten el mismo nombre de usuario de SELinux, y todo el control de acceso se gestiona mediante la tercera etiqueta, el dominio. Las circunstancias en las que se permite el acceso de un proceso a un dominio determinado deben configurarse en las políticas. El comando runconpermite iniciar un proceso en un contexto especificado explícitamente (usuario, rol y dominio), pero SELinux puede denegar la transición si no está aprobada por la política.

Los archivos, los puertos de red y otros componentes de hardware también tienen un contexto SELinux, que consta de un nombre, una función (poco frecuente) y un tipo. En el caso de los sistemas de archivos, la asignación entre los archivos y los contextos de seguridad se denomina etiquetado. El etiquetado se define en los archivos de políticas, pero también se puede ajustar manualmente sin modificar las políticas. Los tipos de hardware son bastante detallados; por ejemplo, bin_t(todos los archivos en la carpeta /bin) o postgresql_port_t(puerto PostgreSQL, 5432). El contexto SELinux para un sistema de archivos remoto se puede especificar explícitamente al montarlo.

SELinux agrega el -Zinterruptor a los comandos de shell ls, ps, y algunos otros, lo que permite ver el contexto de seguridad de los archivos o procesos.

Las reglas de política típicas consisten en permisos explícitos, por ejemplo, qué dominios debe poseer el usuario para realizar ciertas acciones con el objetivo dado (leer, ejecutar o, en el caso de un puerto de red, enlazar o conectarse), etc. También son posibles asignaciones más complejas, que incluyen roles y niveles de seguridad.

Una política típica consta de un archivo de mapeo (etiquetado), un archivo de reglas y un archivo de interfaz que definen la transición de dominio. Estos tres archivos deben compilarse con las herramientas de SELinux para generar un único archivo de política. El archivo resultante se puede cargar en el kernel para activarlo. La carga y descarga de políticas no requiere reiniciar el sistema. Los archivos de política se pueden escribir manualmente o generar con la herramienta de administración de SELinux, más intuitiva. Normalmente, se prueban primero en modo permisivo, donde se registran las infracciones, pero se permiten. audit2allowPosteriormente, la herramienta se puede usar para generar reglas adicionales que amplíen la política y permitan todas las actividades legítimas de la aplicación restringida.

Las características de SELinux incluyen:

• Separación clara entre política y aplicación.
• Interfaces de políticas bien definidas
• Compatibilidad con aplicaciones que consultan la política y aplican el control de acceso (por ejemplo, tareas de crond que se ejecutan en el contexto correcto).
• Independencia de políticas y lenguajes políticos específicos
• Independencia de formatos y contenidos específicos de etiquetas de seguridad
• Etiquetas y controles individuales para objetos y servicios del kernel.
• Apoyo a los cambios de política
• Medidas separadas para proteger la integridad del sistema (tipo de dominio) y la confidencialidad de los datos ( seguridad multinivel ).
• Política flexible
• Controles sobre la inicialización y herencia de procesos, y ejecución de programas.
• Controles sobre sistemas de archivos, directorios, archivos y descriptores de archivos abiertos.
• Controles sobre sockets, mensajes e interfaces de red.
• Controles sobre el uso de "capacidades"
• Información almacenada en caché sobre decisiones de acceso a través de la caché de vector de acceso (AVC) ^{[ 12 ]}
• Política de denegación por defecto (todo lo que no esté especificado explícitamente en la política no está permitido) ^{[ 13 ] [ 14 ] [ 15 ]}

SELinux se ha implementado en Android desde la versión 4.3. ^{[ 16 ]}

Entre las distribuciones Linux gratuitas con soporte de la comunidad, Fedora fue una de las primeras en adoptarlo, incluyendo soporte para ello por defecto desde Fedora Core 2. Otras distribuciones incluyen soporte para ello, como Debian desde la versión 9 Stretch ^{[ 17 ]} y Ubuntu desde la versión 8.04 Hardy Heron. ^{[ 18 ]} Desde la versión 11.1, openSUSE incluye la "habilitación básica" de SELinux. ^{[ 19 ]} SUSE Linux Enterprise (SLE) 11 incluye SELinux como una "vista previa tecnológica". ^{[ 20 ]}

SELinux es popular en sistemas basados ​​en contenedores Linux , como CoreOS Container Linux y rkt. ^{[ 21 ]} Es útil como un control de seguridad adicional para ayudar a reforzar aún más el aislamiento entre los contenedores desplegados y su host.

SELinux está disponible desde 2005 como parte de Red Hat Enterprise Linux (RHEL) versión 4 y todas las versiones futuras. Esta presencia también se refleja en las versiones correspondientes de sistemas derivados como CentOS , Scientific Linux , AlmaLinux y Rocky Linux . La política compatible en RHEL4 es una política dirigida que busca la máxima facilidad de uso y, por lo tanto, no es tan restrictiva como podría ser. Se planea que las futuras versiones de RHEL tengan más objetivos en la política dirigida, lo que significará políticas más restrictivas. RHEL versión 5 introdujo la política de seguridad multinivel (MLS) solo para servidores. Fedora Linux 10 introdujo una política mínima, diseñada para ciertas plataformas como dispositivos con poca memoria y máquinas virtuales . ^{[ 22 ]}

openSUSE Tumbleweed pasó de AppArmor a SELinux para nuevas instalaciones desde el 11 de febrero de 2025, y SLE/openSUSE Leap 16 también se distribuyó con SELinux por defecto. ^{[ 23 ]} openSUSE/SLE adoptó las políticas de RHEL/Fedora para su implementación de SELinux, aunque con algunas diferencias. ^{[ 24 ]} AppArmor se mantiene para las instalaciones existentes de Tumbleweed y SLE/openSUSE Leap 15.x (los usuarios pueden migrar manualmente su instalación existente a SELinux). AppArmor también está disponible como una opción de instalación para los usuarios de Tumbleweed, pero no en SLE/Leap 16. ^{[ 25 ] [ 26 ]}

SELinux puede controlar, con especificaciones muy precisas, las actividades que un sistema permite a cada usuario, proceso y demonio. Se utiliza para restringir demonios como motores de bases de datos o servidores web, que tienen derechos de acceso a datos y de actividad claramente definidos. Esto limita el daño potencial que podría causar un demonio restringido que se vea comprometido.

Las utilidades de línea de comandos incluyen: ^{[ 27 ]}chcon , ^{[ 28 ]}restorecon , ^{[ 29 ]}restorecond , ^{[ 30 ]}runcon , ^{[ 31 ]}secon , ^{[ 32 ]}fixfiles , ^{[ 33 ]}setfiles , ^{[ 34 ]}load_policy , ^{[ 35 ]}booleans , ^{[ 36 ]}getsebool , ^{[ 37 ]}setsebool , ^{[ 38 ]} togglesebool^{[ 39 ]}setenforce , semodule, postfix-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing, ^{[ 40 ]}selinuxenabled , ^{[ 41 ]} y selinux-policy-upgrade^{[ 42 ]}

SELinux representa uno de los diversos enfoques posibles para restringir las acciones que puede realizar el software instalado. Otra alternativa popular es AppArmor , disponible en SUSE Linux Enterprise Server (SLES) (antes de la versión 16), openSUSE y plataformas basadas en Debian . AppArmor se desarrolló como un componente de la plataforma Immunix Linux, ahora desaparecida . Debido a que AppArmor y SELinux difieren radicalmente entre sí, constituyen alternativas distintas para el control de software. Mientras que SELinux reinventa ciertos conceptos para brindar acceso a un conjunto más expresivo de opciones de política, AppArmor se diseñó para ser simple, extendiendo la misma semántica administrativa utilizada para DAC hasta el nivel de control de acceso obligatorio.

Existen varias diferencias clave:

• Una diferencia importante es que AppArmor identifica los objetos del sistema de archivos por su ruta de acceso en lugar de por su inodo. Esto significa que, por ejemplo, un archivo inaccesible puede volverse accesible con AppArmor al crear un enlace físico, mientras que SELinux denegaría el acceso a través de dicho enlace.
  • En consecuencia, se puede decir que AppArmor no es un sistema de imposición de tipos , ya que a los archivos no se les asigna un tipo; en cambio, simplemente se hace referencia a ellos en un archivo de configuración.
• SELinux y AppArmor también difieren significativamente en cómo se administran y cómo se integran en el sistema. ^{[ 43 ]}
• Dado que se esfuerza por recrear los controles DAC tradicionales con aplicación a nivel MAC, el conjunto de operaciones de AppArmor también es considerablemente menor que el disponible en la mayoría de las implementaciones de SELinux. Por ejemplo, el conjunto de operaciones de AppArmor consiste en: leer, escribir, añadir, ejecutar, bloquear y enlazar. ^{[ 44 ]} La mayoría de las implementaciones de SELinux admitirán un número de operaciones mucho mayor. Por ejemplo, SELinux generalmente admitirá esos mismos permisos, pero también incluye controles para mknod, enlace a sockets de red, uso implícito de capacidades POSIX, carga y descarga de módulos del kernel, varios medios de acceso a la memoria compartida, etc.
• AppArmor no incluye controles para delimitar categóricamente las capacidades POSIX. Dado que la implementación actual de capacidades no contempla un sujeto para la operación (solo el actor y la operación), generalmente es responsabilidad de la capa MAC impedir operaciones privilegiadas en archivos fuera del ámbito de control impuesto al actor (es decir, el "Sandbox"). AppArmor puede impedir que se modifique su propia política y que se monten o desmonten sistemas de archivos, pero no impide que los usuarios se salgan de sus ámbitos de control autorizados.
  • Por ejemplo, puede considerarse beneficioso para los empleados de soporte técnico cambiar la propiedad o los permisos de ciertos archivos, incluso si no son los propietarios (por ejemplo, en un recurso compartido de archivos departamental). El administrador no quiere dar acceso de root al usuario o usuarios en el servidor, por lo que les da CAP_FOWNERo CAP_DAC_OVERRIDE. En SELinux, el administrador (o el proveedor de la plataforma) puede configurar SELinux para denegar todas las capacidades a los usuarios que de otro modo no estarían restringidos, y luego crear dominios restringidos para que el empleado pueda acceder después de iniciar sesión, uno que puede ejercer esas capacidades, pero solo en archivos del tipo apropiado.
• AppArmor no contempla la seguridad multinivel, por lo que no dispone de una aplicación estricta de BLP o Biba .
• La configuración de AppArmor se realiza utilizando únicamente archivos planos regulares. SELinux (por defecto en la mayoría de las implementaciones) utiliza una combinación de archivos planos (utilizados por administradores y desarrolladores para escribir políticas legibles antes de su compilación) y atributos extendidos.
• SELinux admite el concepto de "servidor de políticas remoto" (configurable mediante /etc/selinux/semanage.conf) como fuente alternativa para la configuración de políticas. La administración centralizada de AppArmor suele ser bastante compleja, ya que los administradores deben decidir entre ejecutar las herramientas de implementación de configuración como root (para permitir actualizaciones de políticas) o configurarlas manualmente en cada servidor.

El aislamiento de procesos también puede lograrse mediante mecanismos como la virtualización .

La NSA ha adoptado algunos de los conceptos de SELinux en Security-Enhanced Android . ^{[ 45 ]}

General Dynamics crea y distribuye PitBull Trusted Operating System, ^{[ 46 ]} una mejora de seguridad multinivel (MLS) para Red Hat Enterprise Linux .

La seguridad multicategoría (MCS) es una mejora de SELinux para Red Hat Enterprise Linux que permite a los usuarios etiquetar archivos con categorías, con el fin de restringir aún más el acceso mediante el control de acceso discrecional y la aplicación de tipos. Las categorías proporcionan compartimentos adicionales dentro de los niveles de sensibilidad utilizados por la seguridad multinivel (MLS). ^{[ 47 ]}

• AppArmor : módulo de seguridad del kernel de Linux 
• Astra Linux : sistema operativo ruso basado en Linux. 
• Control de acceso basado en conjuntos de reglas (RSBAC) : marco de control de acceso para el kernel de Linux. 
• Núcleo de control de acceso obligatorio simplificado : módulo de seguridad del núcleo de Linux. Páginas que muestran breves descripciones de los destinos de redirección. 
• Solaris Trusted Extensions : extensiones de seguridad para el sistema operativo Solaris. 
• Tomoyo – Módulo de seguridad del kernel de Linux. Páginas que muestran breves descripciones de los destinos de redirección. 
• TrustedBSD – Sistema operativo tipo Unix gratuito y de código abierto. Páginas que muestran breves descripciones de los destinos de redirección. 
• Seguridad de Unix
• Qubes OS : sistema operativo basado en Linux centrado en la seguridad. 

• Sitio web oficial