Linux con seguridad mejorada

SELinux

Interfaz gráfica de usuario del administrador de SELinux en Arch Linux
Autor(es) original(es)	La NSA y Red Hat
Desarrollador(es)	Sombrero rojo
Lanzamiento inicial	22 de diciembre de 2000 ; hace 23 años [1] ( 22 de diciembre de 2000 )
Versión estable	3.6 / 13 de diciembre de 2023 ; hace 10 meses [2] ( 13-12-2023 )
Repositorio	github.com/SELinuxProject/selinux
Escrito en	do
Sistema operativo	Linux
Tipo	Seguridad, módulos de seguridad de Linux (LSM)
Licencia	Licencia Pública General de GNU
Sitio web	selinuxproject.org , https://www.nsa.gov/what-we-do/research/selinux/

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:

• Separación clara entre política y ejecución
• Interfaces de políticas bien definidas
• Soporte para aplicaciones que consultan la política y aplican el control de acceso (por ejemplo, crond que ejecuta trabajos en el contexto correcto)
• Independencia de políticas específicas y lenguajes de políticas
• Independencia de formatos y contenidos específicos de etiquetas de seguridad
• Etiquetas y controles individuales para objetos y servicios del núcleo
• Apoyo a los cambios de políticas
• 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 la 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 las “capacidades”
• Información almacenada en caché sobre decisiones de acceso a través de la caché de vector de acceso (AVC) ^[8]
• Política de denegación predeterminada (todo lo que no esté especificado explícitamente en la política no está permitido) ^{[9] [10] [11]}

SELinux 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] , [ ²⁹ ] , [ ^30] , [ ^31] , ^[32] y ^[33]seconfixfilessetfilesload_policybooleansgetseboolsetsebooltoggleseboolsetenforcesemodulepostfix-nochrootcheck-selinux-installationsemodule_packagecheckmoduleselinux-config-enforcingselinuxenabledselinux-policy-upgrade

Para poner SELinux en modo de aplicación:

setenforce 1

Para consultar el estado de SELinux:

getenforce

SELinux 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:

• Una diferencia importante es que AppArmor identifica los objetos del sistema de archivos por el nombre de la ruta en lugar de por el inodo. Esto significa que, por ejemplo, un archivo que es inaccesible puede volverse accesible con AppArmor cuando se crea un enlace físico hacia él, mientras que SELinux denegaría el acceso a través del enlace físico recién creado.
  • Como resultado, se puede decir que AppArmor no es un sistema de cumplimiento 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. ^[34]
• Dado que intenta recrear los controles DAC tradicionales con aplicación a nivel MAC, el conjunto de operaciones de AppArmor también es considerablemente más pequeño que el disponible en la mayoría de las implementaciones de SELinux. Por ejemplo, el conjunto de operaciones de AppArmor consiste en: leer, escribir, agregar, ejecutar, bloquear y vincular. ^[35] La mayoría de las implementaciones de SELinux admitirán un número de operaciones de órdenes de magnitud superiores a ese. Por ejemplo, SELinux normalmente admitirá esos mismos permisos, pero también incluye controles para mknod, vinculación a sockets de red, uso implícito de capacidades POSIX, carga y descarga de módulos del núcleo, varios medios de acceso a la memoria compartida, etc.
• En AppArmor no existen controles para delimitar categóricamente las capacidades POSIX. Dado que la implementación actual de capacidades no contiene ninguna noción de un sujeto para la operación (solo el actor y la operación), normalmente es tarea de la capa MAC evitar operaciones privilegiadas en archivos fuera del ámbito de control impuesto por el actor (es decir, "Sandbox"). AppArmor puede evitar que se altere su propia política y evitar que se monten o desmonten sistemas de archivos, pero no hace nada para evitar que los usuarios salgan de sus ámbitos de control aprobados.
  • Por ejemplo, puede resultar beneficioso para los empleados de la mesa de ayuda cambiar la propiedad o los permisos de determinados archivos, incluso si no son sus propietarios (por ejemplo, en un recurso compartido de archivos departamental). El administrador no quiere dar a los usuarios acceso de root en el equipo, 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 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 ]}
• No existe un concepto de seguridad multinivel con AppArmor, por lo que no hay disponible una aplicación estricta de BLP o Biba . ^{[ cita requerida ]} .
• La configuración de AppArmor se realiza utilizando únicamente archivos planos normales. SELinux (de manera predeterminada en la mayoría de las implementaciones) utiliza una combinación de archivos planos (utilizados por administradores y desarrolladores para escribir políticas legibles para humanos antes de compilarlas) y atributos extendidos.
• SELinux admite el concepto de un "servidor de políticas remoto" (configurable a través de /etc/selinux/semanage.conf) como una fuente alternativa para la configuración de políticas. La administración central de AppArmor suele ser bastante complicada, ya que los administradores deben decidir entre ejecutar 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 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]

• AppArmor  : módulo de seguridad del kernel de Linux
• Astra Linux  : sistema operativo informático basado en Linux de origen ruso
• Red Star OS  : sistema operativo norcoreano basado en Linux
• Control de acceso basado en conjuntos de reglas (RSBAC)  : marco de control de acceso para el kernel de Linux
• Kernel de control de acceso obligatorio simplificado  : módulo de seguridad del kernel de LinuxPáginas que muestran descripciones breves de los objetivos de redireccionamiento
• Solaris Trusted Extensions  : extensiones de seguridad para el sistema operativo Solaris
• Tomoyo  – Módulo de seguridad del kernel de LinuxPáginas que muestran descripciones breves de los objetivos de redireccionamiento
• TrustedBSD  : sistema operativo tipo Unix gratuito y de código abiertoPáginas que muestran descripciones breves de los objetivos de redireccionamiento
• Seguridad de Unix
• Qubes OS  : sistema operativo basado en Linux centrado en la seguridad

• Sitio web oficial
• Linux con seguridad mejorada en la Agencia de Seguridad Nacional en Internet Archive
• SELinux en GitHub
• Walsh, Daniel J (13 de noviembre de 2013). "Guía visual de procedimientos para la aplicación de políticas de SELinux". Opensource.com.