Security-Enhanced Linux ( SELinux ) es un módulo de seguridad del kernel de Linux que proporciona un mecanismo para respaldar 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 intenta 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. [3] [4] Los conceptos clave que subyacen a SELinux se pueden rastrear hasta varios proyectos anteriores de la Agencia de Seguridad Nacional de los Estados Unidos (NSA).
El equipo de Linux mejorado con seguridad de la NSA describe a NSA SELinux como [5]
Un conjunto de parches para el núcleo de Linux y utilidades para proporcionar una arquitectura de control de acceso (MAC) obligatoria, fuerte y flexible a los principales subsistemas del núcleo. Proporciona un mecanismo mejorado para hacer cumplir la separación de la información en función de los requisitos de confidencialidad e integridad, lo que permite abordar las amenazas de manipulación y eludir los mecanismos de seguridad de las aplicaciones y permite limitar los daños que pueden causar las aplicaciones maliciosas o defectuosas. Incluye un conjunto de archivos de configuración de políticas de seguridad de muestra diseñados para cumplir con los objetivos de seguridad comunes y de uso general.
Un núcleo 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 los archivos y los recursos de red. Limitar los privilegios al mínimo necesario para funcionar 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 funciona de forma independiente de los mecanismos de control de acceso tradicionales de Linux ( discrecionales ). No tiene el concepto de un superusuario "root" y no comparte las deficiencias bien conocidas de los mecanismos de seguridad tradicionales de Linux, como la dependencia de los 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 privilegiadas y de cada una de sus configuraciones. Un fallo en cualquiera de estas áreas puede permitir el compromiso de todo el sistema. Por el contrario, la seguridad de un sistema "modificado" (basado en un núcleo SELinux) depende principalmente de la corrección del núcleo y de su configuración de políticas de seguridad. Aunque los problemas con la corrección o configuración de las aplicaciones pueden permitir el compromiso limitado de programas de usuario individuales y daemons del sistema, no necesariamente suponen una amenaza para la seguridad de otros programas de usuario y daemons del sistema o para la seguridad del sistema en su conjunto.
Desde una perspectiva purista, SELinux ofrece una combinación de conceptos y capacidades extraídos de los controles de acceso obligatorios, los controles de integridad obligatorios , el control de acceso basado en roles (RBAC) y la 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 proporcione 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ó entre 1987 y 1991 y publicó un Rainbow Book (#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 para la comunidad Linux y cómo dichos controles podrían agregarse a Linux. Originalmente, los parches que conforman 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 original de SELinux, lanzó la primera versión a la comunidad de desarrollo de código abierto bajo la licencia GNU GPL el 22 de diciembre de 2000. [6] El software se fusionó con el núcleo Linux principal 2.6.0-test3, lanzado el 8 de agosto de 2003. Otros contribuyentes importantes incluyen a Red Hat , Network Associates , Secure Computing Corporation , Tresys Technology y Trusted Computer Solutions. Se han puesto a disposición puertos experimentales de la implementación de FLASK /TE a través del Proyecto TrustedBSD para los sistemas operativos FreeBSD y Darwin .
Security-Enhanced Linux implementa el Flux Advanced Security Kernel (FLASK). Este kernel contiene componentes arquitectónicos prototipados en el sistema operativo Fluke. Estos proporcionan soporte general para aplicar muchos tipos de políticas de control de acceso obligatorias, incluidas las 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 e implementación de DTOS. [ cita requerida ]
En el sitio web de la NSA se alojó una lista completa de los colaboradores originales y externos de SELinux hasta que cesó su mantenimiento en algún momento de 2009. La siguiente lista reproduce la original tal como la conservó Internet Archive Wayback Machine. El alcance de sus contribuciones se incluyó en la página y se omitió por razones de brevedad, pero se puede acceder a ella a través de la copia archivada. [7]
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 que consiste en un nombre de usuario, rol y dominio (o tipo). Este sistema es más flexible de lo que normalmente se requiere: como regla, 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 dominio determinado deben configurarse en las políticas. El comando runconpermite el lanzamiento de 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, puertos de red y otro hardware también tienen un contexto SELinux, que consta de un nombre, una función (que rara vez se utiliza) 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 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 -Zconmutador 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 determinadas acciones con el objetivo determinado (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 se deben compilar junto con las herramientas de SELinux para producir un único archivo de política. El archivo de política resultante se puede cargar en el núcleo para activarlo. La carga y descarga de políticas no requiere un reinicio. Los archivos de política se escriben a mano o se pueden generar desde la herramienta de administración de SELinux, que es más fácil de usar. Normalmente, primero se prueban en modo permisivo, donde se registran las violaciones, 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. [12]
Entre las distribuciones Linux gratuitas con soporte comunitario, Fedora fue una de las primeras en adoptarla, y la admite de forma predeterminada desde Fedora Core 2. Otras distribuciones la admiten, como Debian a partir de la versión 9 Stretch [13] y Ubuntu a partir de la versión 8.04 Hardy Heron. [14] A partir de la versión 11.1, openSUSE contiene la "habilitación básica" de SELinux. [15] SUSE Linux Enterprise 11 incluye SELinux como una "versión preliminar de tecnología". [16]
SELinux es popular en sistemas basados en contenedores Linux , como CoreOS Container Linux y rkt. [17] Es útil como un control de seguridad adicional para ayudar a reforzar 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 dirigida que apunta a 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.
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 acceso a datos y de actividad claramente definidos. Esto limita el daño potencial de un demonio confinado que se ve comprometido.
Las utilidades de línea de comandos incluyen: [18]chcon , [19]restorecon , [20]restorecond , [21] , [22]runcon , [ 23 ], [24 ] , [ 25 ] , [26] , [27] , [28] , [ 29 ] , [ 30] , [ 31] , [32]
y [33]seconfixfilessetfilesload_policybooleansgetseboolsetsebooltoggleseboolsetenforcesemodulepostfix-nochrootcheck-selinux-installationsemodule_packagecheckmoduleselinux-config-enforcingselinuxenabledselinux-policy-upgrade
Para poner SELinux en modo de aplicación:
setenforce 1Para consultar el estado de SELinux:
getenforceSELinux representa uno de los 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 ahora desaparecida plataforma Linux Immunix . 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 proporcionar 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.
Existen varias diferencias clave:
CAP_FOWNERo CAP_DAC_OVERRIDE. En SELinux, el administrador (o el proveedor de la plataforma) puede configurar SELinux para denegar todas las capacidades a usuarios que de otro modo no estarían restringidos, y luego crear dominios restringidos para que el empleado pueda realizar la transición después de iniciar sesión, uno que pueda ejercer esas capacidades, pero solo en archivos del tipo apropiado. [ cita requerida ]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 [36] aisló aplicaciones individuales en servidores virtuales ligeros . Además, la NSA ha adoptado algunos de los conceptos de SELinux en Security-Enhanced Android . [37]
General Dynamics crea y distribuye PitBull Trusted Operating System, [38] 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 para 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). [39]
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 denegar el acceso, se almacenan en caché. Esta caché se conoce como caché de vector de acceso (AVC). El almacenamiento en caché de las decisiones reduce la frecuencia con la que se deben verificar las reglas de SELinux, lo que aumenta el rendimiento.
