Linux con seguridad mejorada

Linux con seguridad mejorada (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 kernel y herramientas de espacio de usuario que se han agregado a varias distribuciones de Linux. Su arquitectura se esfuerza por separar la aplicación de las decisiones de seguridad de la política de seguridad y agiliza la cantidad de software involucrado en la aplicación de la política de seguridad. Los conceptos clave que subyacen a SELinux se remontan a varios proyectos anteriores de la Agencia de Seguridad Nacional (NSA) de los Estados Unidos.

Resumen

El equipo de seguridad mejorada de Linux de la NSA describe NSA SELinux como

a set of patches to the Linux kernel and utilities to provide a strong, flexible, mandatory access control (MAC) architecture into the major subsystems of the kernel. Proporciona un mecanismo mejorado para hacer cumplir la separación de información basada en requisitos de confidencialidad e integridad, lo que permite que se aborden las amenazas de manipulación y eludir los mecanismos de seguridad de la aplicación y permite el confinamiento de daños que pueden ser causados por aplicaciones malintencionadas o defectuosas. Incluye un conjunto de archivos de configuración de políticas de seguridad de muestra diseñados para cumplir con objetivos comunes de seguridad para fines generales.

Un kernel de Linux que integra SELinux aplica políticas de control de acceso obligatorias que limitan 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 requerido para trabajar reduce o elimina la capacidad de estos programas y demonios de causar daños si fallan o se ven comprometidos (por ejemplo, a través de desbordamientos de búfer o configuraciones incorrectas). Este mecanismo de confinamiento opera independientemente de los mecanismos tradicionales de control de acceso (discrecionales) de Linux. No tiene el concepto de "raíz" superusuario, y no comparte las conocidas deficiencias de los mecanismos de seguridad tradicionales de Linux, como la dependencia de los binarios setuid/setgid.

La seguridad de un "no modificado" El sistema Linux (un sistema sin SELinux) depende de la corrección del kernel, de todas las aplicaciones privilegiadas y de cada una de sus configuraciones. Una falla en cualquiera de estas áreas puede permitir el compromiso de todo el sistema. Por el contrario, la seguridad de un "modificado" (basado en un kernel SELinux) depende principalmente de la corrección del kernel y de su configuración de política de seguridad. Si bien los problemas con la corrección o configuración de las aplicaciones pueden permitir el compromiso limitado de programas de usuario individuales y demonios del sistema, no representan necesariamente una amenaza para la seguridad de otros programas de usuario y demonios del sistema o para la seguridad del sistema en su conjunto.

Desde una perspectiva purista, SELinux ofrece un híbrido de conceptos y capacidades extraídos de los controles de acceso obligatorios, los controles de integridad obligatorios, el control de acceso basado en funciones (RBAC) y la arquitectura de cumplimiento de tipos. Las herramientas de terceros permiten crear una variedad de políticas de seguridad.

Historia

El primer trabajo dirigido a estandarizar un enfoque que proporciona controles de acceso obligatorios y discrecionales (MAC y DAC) dentro de un entorno informático UNIX (más precisamente, POSIX) se puede atribuir a Trusted UNIX (TRUSIX) de la Agencia de Seguridad Nacional. Grupo de Trabajo, 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 asociado (#020B) que finalmente no se publicó.

SELinux fue diseñado para demostrar el valor de los controles de acceso obligatorios a la comunidad de Linux y cómo dichos controles podrían agregarse a Linux. Originalmente, los parches que componen SELinux debían aplicarse explícitamente al código fuente del kernel de Linux; SELinux se fusionó con la línea principal del kernel de Linux en la serie 2.6 del kernel de Linux.

La NSA, el desarrollador principal original de SELinux, lanzó la primera versión a la comunidad de desarrollo de código abierto bajo la GPL de GNU el 22 de diciembre de 2000. El software se fusionó con el kernel principal de Linux 2.6.0-test3, lanzado el 8 de agosto de 2003. Otros contribuyentes importantes incluyen Red Hat, Network Associates, Secure Computing Corporation, Tresys Technology y Trusted Computer Solutions. Los puertos experimentales de la implementación de FLASK/TE están disponibles a través del Proyecto TrustedBSD para los sistemas operativos FreeBSD y Darwin.

Linux con seguridad mejorada implementa el núcleo de seguridad avanzada Flux (FLASK). Dicho núcleo contiene componentes arquitectónicos creados en prototipos en el sistema operativo Fluke. Estos brindan soporte general para hacer cumplir muchos tipos de políticas de control de acceso obligatorias, incluidas aquellas basadas en los conceptos de aplicación de tipo, control de acceso basado en roles y seguridad multinivel. FLASK, a su vez, se basó en DTOS, un sistema operativo confiable distribuido derivado de Mach, así como en Trusted Mach, un proyecto de investigación de Trusted Information Systems que influyó en el diseño e implementación de DTOS.

Contribuidores originales y externos

Una lista completa de los colaboradores originales y externos de SELinux se alojó en el sitio web de la NSA hasta que cesó el mantenimiento, en algún momento de 2009. La siguiente lista reproduce el original conservado por Internet Archive Wayback Machine. El alcance de sus contribuciones se enumeró en la página y se ha omitido por brevedad, pero se puede acceder a él a través de la copia archivada.

Usuarios, políticas y contextos de seguridad

Los usuarios y roles de SELinux no tienen que estar relacionados con los usuarios y roles reales del sistema. Para cada usuario o proceso actual, SELinux asigna un contexto de tres cadenas que consta de un nombre de usuario, rol y dominio (o tipo). Este sistema es más flexible de lo que normalmente se requiere: por regla general, la mayoría de los usuarios reales comparten el mismo nombre de usuario de SELinux y todo el control de acceso se administra a través de la tercera etiqueta, el dominio. Las circunstancias bajo las cuales se permite que un proceso ingrese a un determinado dominio deben configurarse en las políticas. El comando runcon permite el lanzamiento de un proceso en un contexto explícitamente especificado (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 otro hardware también tienen un contexto SELinux, que consta de un nombre, una función (rara vez se usa) y un tipo. En el caso de los sistemas de archivos, la asignación entre 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 cambiar 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 de SELinux para un sistema de archivos remoto se puede especificar explícitamente en el momento del montaje.

SELinux agrega el interruptor -Z a los comandos de shell ls, ps y algunos otros, lo que permite que el contexto de seguridad de los archivos o proceso para ser visto.

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 destino determinado (leer, ejecutar o, en el caso de un puerto de red, enlazar o conectar), etc. También son posibles asignaciones más complejas, que involucran 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 del dominio. Estos tres archivos deben compilarse junto con las herramientas de SELinux para generar un solo archivo de políticas. El archivo de política resultante se puede cargar en el kernel para activarlo. Las políticas de carga y descarga no requieren un reinicio. Los archivos de políticas están escritos a mano o pueden generarse desde la herramienta de administración SELinux más fácil de usar. Normalmente se prueban primero en modo permisivo, donde las infracciones se registran pero se permiten. La herramienta audit2allow se puede usar más adelante para producir reglas adicionales que amplíen la política para permitir que se limiten todas las actividades legítimas de la aplicación.

Características

Las características de SELinux incluyen:

• Separación limpia de la política de la aplicación
• Interfaz de política bien definida
• Apoyo a las aplicaciones que cuestionan la política y la aplicación del control de acceso (por ejemplo, empleos en funcionamiento de la varita en el contexto correcto)
• Independencia de políticas e idiomas normativos específicos
• Independencia de formatos y contenidos específicos de seguridad
• Etiquetas y controles individuales para objetos y servicios del kernel
• Apoyo a los cambios normativos
• 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 del proceso y la herencia, y ejecución del programa
• Controles sobre sistemas de archivos, directorios, archivos y descriptores de archivos abiertos
• Controles sobre tomas, mensajes e interfaces de red
• Controles sobre el uso de "capacidades"
• Información sobre las decisiones de acceso a través de las Access Vector Cache (AVC)
• Política de denegación por incumplimiento (cualquier cosa que no se especifique explícitamente en la política se desactiva)

Implementaciones

sestatus mostrando el estado de SELinux en un sistema

SELinux se ha implementado en Android desde la versión 4.3.

Entre las distribuciones gratuitas de Linux compatibles con la comunidad, Fedora fue una de las primeras en adoptarlo, incluido el soporte predeterminado desde Fedora Core 2. Otras distribuciones incluyen soporte como Debian a partir de la versión 9 Stretch y Ubuntu a partir de la 8.04. Garza dura. A partir de la versión 11.1, openSUSE contiene la "habilitación básica" de SELinux. SUSE Linux Enterprise 11 presenta SELinux como una "vista previa de la tecnología".

SELinux es popular en sistemas basados en contenedores de Linux, como CoreOS Container Linux y rkt. Es útil como control de seguridad adicional para ayudar a aplicar aún más el aislamiento entre los contenedores implementados y su host.

SELinux está disponible desde 2005 como parte de la versión 4 de Red Hat Enterprise Linux (RHEL) y todas las versiones futuras. Esta presencia también se refleja en las versiones correspondientes de CentOS y Scientific Linux. La política admitida en RHEL4 es una política específica que tiene como objetivo la máxima facilidad de uso y, por lo tanto, no es tan restrictiva como podría ser. Se planea que las versiones futuras de RHEL tengan más objetivos en la política específica, lo que significará políticas más restrictivas.

Usar escenarios

SELinux puede controlar potencialmente qué actividades permite un sistema a cada usuario, proceso y daemon, con especificaciones muy precisas. Se utiliza para confinar demonios como motores de base de datos o servidores web que tienen derechos de actividad y acceso a datos claramente definidos. Esto limita el daño potencial de un demonio confinado que se ve comprometido.

Las utilidades de la línea de comandos incluyen: chcon, restauración, restorecond, runcon, segundo, arreglar archivos, establecer archivos, load_policy, booleanos, getsebool, setsebool, alternar sebool setenforce, semodule, postfix-nochroot, verificar-instalación-de-selinux, semodule_package, módulo de control, selinux-config-enforcing, selinux habilitado, y selinux-policy-upgrade

Ejemplos

Para poner SELinux en modo de cumplimiento:

$ sudo setenforce 1

Para consultar el estado de SELinux:

$ getenforce

Comparación con AppArmor

SELinux representa uno de varios enfoques posibles para el problema de restringir las acciones que puede realizar el software instalado. Otra alternativa popular se llama AppArmor y está disponible en SUSE Linux Enterprise Server (SLES), 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í, forman distintas alternativas para el control del software. Mientras que SELinux reinventa ciertos conceptos para brindar acceso a un conjunto más expresivo de opciones de políticas, AppArmor fue diseñado para ser simple al extender la misma semántica administrativa utilizada para DAC hasta el nivel de control de acceso obligatorio.

Hay varias diferencias clave:

• Una diferencia importante es que AppArmor identifica objetos del sistema de archivos por nombre de ruta en lugar de inode. Esto significa que, por ejemplo, un archivo que es inaccesible puede llegar a ser accesible bajo AppArmor cuando se crea un vínculo duro con él, mientras que SELinux negaría el acceso a través del nuevo enlace duro creado.
  • Como resultado, AppArmor puede decirse que no es un sistema de cumplimiento de tipo, ya que los archivos no se asignan un tipo; en cambio, son meramente referenciados 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.
• Dado que se esfuerza por recrear los controles tradicionales del DAC con la aplicación del MAC, el conjunto de operaciones de AppArmor también es considerablemente menor que los disponibles en la mayoría de las implementaciones de SELinux. Por ejemplo, el conjunto de operaciones de AppArmor consiste en: leer, escribir, apéndice, ejecutar, bloquear y vincular. La mayoría de las implementaciones de SELinux apoyarán el número de órdenes de operaciones de magnitud más que eso. Por ejemplo, SELinux suele apoyar esos mismos permisos, pero también incluye controles para mknod, unión a tomas de red, uso implícito de capacidades POSIX, carga y descarga de módulos de núcleo, varios medios de acceder a la memoria compartida, etc.
• No hay controles en AppArmor para clasificar las capacidades POSIX. Dado que la implementación actual de las capacidades no contiene la noción de un sujeto para la operación (sólo el actor y la operación) es generalmente el trabajo de la capa MAC para prevenir operaciones privilegiadas en archivos fuera del reino de control forzado del actor (es decir, "Sandbox"). AppArmor puede evitar que su propia política sea alterada, e impedir que los sistemas de archivos sean montados o no montados, pero no hace nada para evitar que los usuarios salgan de sus dominios de control aprobados.
  • Por ejemplo, puede considerarse beneficioso que los empleados de la oficina de ayuda cambien la propiedad o los permisos en ciertos archivos, incluso si no los poseen (por ejemplo, en una parte de archivo departamental). El administrador no quiere dar al usuario(s) acceso raíz en la caja por lo que les dan CAP_FOWNER o CAP_DAC_OVERRIDE. Bajo SELinux el administrador (o proveedor de plataforma) puede configurar SELinux para negar todas las capacidades a los usuarios no definidos de otra manera, luego crear dominios confinados para que el empleado pueda pasar después de iniciar sesión, uno que puede ejercer esas capacidades, pero sólo en archivos del tipo apropiado.
• No existe una noción de seguridad multinivel con AppArmor, por lo que no hay ninguna aplicación BLP o Biba difícil disponible..
• La configuración 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 la política legible humana antes de que se compila) y atributos extendidos.
• SELinux apoya el concepto de "remote policy server" (configurable a través /etc/selinux/semanage.conf) como una fuente alternativa para la configuración de políticas. La gestión central de AppArmor suele ser complicada, ya que los administradores deben decidir entre las herramientas de implementación de configuración que se están ejecutando como root (para permitir actualizaciones de políticas) o configuradas manualmente en cada servidor.

Sistemas similares y mejoras

El aislamiento de procesos también se puede lograr mediante mecanismos como la virtualización; el proyecto OLPC, por ejemplo, en su primera implementación de aplicaciones individuales aisladas en Vservers ligeros. Además, la NSA ha adoptado algunos de los conceptos de SELinux en Android con seguridad mejorada.

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

Multi-Category Security (MCS) es una mejora de SELinux para Red Hat Enterprise Linux que permite a los usuarios etiquetar archivos con categorías para restringir aún más el acceso a través del 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).