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 racionaliza la cantidad de software involucrado en la aplicación de la política de seguridad. [3] [4] Los conceptos clave que subyacen a SELinux se remontan a varios proyectos anteriores de la Agencia de Seguridad Nacional de los Estados Unidos (NSA).
El equipo de Linux con seguridad mejorada de la NSA describe a NSA SELinux como [5]
un conjunto de parches para el kernel de Linux y utilidades para proporcionar una arquitectura de control de acceso (MAC) fuerte, flexible y obligatoria en los principales subsistemas del kernel. Proporciona un mecanismo mejorado para hacer cumplir la separación de la información basándose en 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 permite limitar el daño que pueden causar aplicaciones maliciosas o defectuosas. Incluye un conjunto de archivos de configuración de políticas de seguridad de muestra diseñados para cumplir objetivos de seguridad comunes y de uso general.
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 funcionar reduce o elimina la capacidad de estos programas y demonios de causar daño si fallan o se ven comprometidos (por ejemplo, mediante desbordamientos del 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 superusuario "root" 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 sistema Linux "no modificado" (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 comprometer todo el sistema. En contraste, la seguridad de un sistema "modificado" (basado en un kernel SELinux) depende principalmente de la corrección del kernel y su configuración de política de seguridad. Si bien los problemas con la corrección o configuración de las aplicaciones pueden permitir un compromiso limitado de programas de usuario individuales y demonios del sistema, no necesariamente representan 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 proporciona un híbrido de conceptos y capacidades extraídas 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 una variedad de políticas de seguridad.
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 al Grupo de Trabajo Trusted UNIX (TRUSIX) de la Agencia de Seguridad Nacional , que se reunió de 1987 a 1991 y publicó un Rainbow Book (#020A), y produjo un modelo formal y un prototipo de evidencia de evaluación asociada (#020B) que finalmente no se publicó.
SELinux fue diseñado para demostrar el valor de los controles de acceso obligatorios a la comunidad 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 GNU GPL el 22 de diciembre de 2000. [6] 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 FLASK /TE están disponibles a través del Proyecto TrustedBSD para los sistemas operativos FreeBSD y Darwin .
Linux con seguridad mejorada implementa el kernel de seguridad avanzada Flux (FLASK). Dicho núcleo contiene componentes arquitectónicos creados en el sistema operativo Fluke. Estos brindan soporte general para aplicar muchos tipos de políticas de control de acceso obligatorias, 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 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 y la implementación de DTOS. [ cita necesaria ]
Una lista completa de los contribuyentes originales y externos de SELinux estuvo alojada 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 figura en la página y se ha omitido por motivos de brevedad, pero se puede acceder a él a través de la copia archivada. [7]
Linus Torvalds , el creador del kernel de Linux , bromeó durante un discurso de apertura en LinuxCon el 18 de septiembre de 2013 diciendo que la Agencia de Seguridad Nacional , los creadores de SELinux , querían una puerta trasera en el kernel. [8] Sin embargo, más tarde, el padre de Linus reveló que la NSA en realidad había solicitado la instalación de puertas traseras en Linux. [9]
Cuando a mi hijo mayor [Linus Torvalds] le hicieron la misma pregunta: "¿La NSA se ha acercado a él para hablar de puertas traseras?" Él dijo “No”, pero al mismo tiempo asintió. Luego estuvo como en libertad legal. Había dado la respuesta correcta, [pero] todos entendieron que la NSA se había acercado a él.
— Nils Torvalds, Comisión LIBE de investigación sobre la vigilancia masiva electrónica de ciudadanos de la UE [10] - 11.ª audiencia, 11 de noviembre de 2013 [11]
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 gestiona 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 runconpermite el lanzamiento de un proceso en un contexto explícitamente especificado (usuario, rol y dominio), pero SELinux puede negar la transición si no está aprobada por la política.
Los archivos, puertos de red y otro hardware también tienen un contexto SELinux, que consta de un nombre, función (rara vez se usa) y tipo. En el caso de los sistemas de archivos, el mapeo entre archivos y contextos de seguridad se llama etiquetado. El etiquetado se define en 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 SELinux para un sistema de archivos remoto se puede especificar explícitamente en el momento del montaje.
SELinux agrega el -Zmodificador a los comandos del shell ls, psy algunos otros, permitiendo 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, vincular 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 SELinux para producir un único archivo de política. El archivo de política resultante se puede cargar en el kernel para activarlo. La carga y descarga de políticas no requiere reiniciar. 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 audit2allowherramienta se puede utilizar 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.
Las características de SELinux incluyen:
sestatusmostrando el estado de SELinux en un sistemaSELinux se ha implementado en Android desde la versión 4.3. [dieciséis]
Entre las distribuciones de Linux gratuitas respaldadas por la comunidad, Fedora fue una de las primeras en adoptarlo, incluido el soporte predeterminado desde Fedora Core 2. Otras distribuciones incluyen soporte para él, como Debian a partir de la versión 9 Stretch release [17] y Ubuntu a partir de la 8.04. Garza resistente. [18] A partir de la versión 11.1, openSUSE contiene la "habilitación básica" de SELinux. [19] SUSE Linux Enterprise 11 presenta SELinux como una "vista previa de la tecnología". [20]
SELinux es popular en sistemas basados en contenedores de Linux , como CoreOS Container Linux y rkt. [21] Es útil como control de seguridad adicional para ayudar a imponer aún más el aislamiento entre los contenedores implementados 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 admitida en RHEL4 es una política específica que apunta a la máxima facilidad de uso y, por lo tanto, no es tan restrictiva como podría ser. Está previsto que las versiones futuras de RHEL tengan más objetivos en la política específica, lo que significará políticas más restrictivas.
SELinux puede controlar potencialmente qué actividades permite un sistema a cada usuario, proceso y demonio, con especificaciones muy precisas. Se utiliza para confinar demonios como motores de bases 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 línea de comandos incluyen: [22]chcon , [23]restorecon , [24]restorecond , [25]runcon , [26]secon , [27]fixfiles , [28]setfiles , [29]load_policy , [30]booleans , [31]getsebool , [32]setsebool , [33] togglesebool[34]setenforce , semodule, postfix-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing, [35]selinuxenabled , [36]
y selinux-policy-upgrade[37]
Para poner SELinux en modo obligatorio:
setenforce 1Para consultar el estado de SELinux:
getenforceSELinux representa uno de varios enfoques posibles al problema de restringir las acciones que puede realizar el software instalado. Otra alternativa popular se llama AppArmor y está disponible en plataformas SUSE Linux Enterprise Server (SLES), openSUSE y basadas en Debian . AppArmor se desarrolló como un componente de la ahora desaparecida plataforma Immunix Linux . Debido a que AppArmor y SELinux difieren radicalmente entre sí, forman 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í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:
CAP_FOWNERo CAP_DAC_OVERRIDE. En SELinux, el administrador (o proveedor de plataforma) puede configurar SELinux para negar todas las capacidades a usuarios que de otro modo no estarían confinados, y luego crear dominios confinados para que el empleado pueda realizar la transición después de iniciar sesión, uno que pueda ejercer esas capacidades, pero solo sobre archivos de el tipo apropiado. [ cita necesaria ]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 [40] protegió aplicaciones individuales en servidores Vservers livianos . Además, la NSA ha adoptado algunos de los conceptos de SELinux en Android con seguridad mejorada . [41]
General Dynamics construye y distribuye PitBull Trusted Operating System, [42] 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 mediante control de acceso discrecional y aplicación de tipos. Las categorías proporcionan compartimentos adicionales dentro de los niveles de sensibilidad utilizados por la seguridad multinivel (MLS). [43]
La NSA se complace en anunciar que ha desarrollado y está poniendo a disposición del público una versión prototipo de un sistema operativo Linux con seguridad mejorada.
Las decisiones de SELinux, como permitir o no permitir el acceso, se almacenan en caché. Esta caché se conoce como caché de vector de acceso (AVC). Las decisiones de almacenamiento en caché reducen la frecuencia con la que se deben verificar las reglas de SELinux, lo que aumenta el rendimiento.
