Linux Security Modules: ¿hay vida más allá de SELinux y AppArmor?

Aunque en mi curso Linux lo explico en el bloque temático sobre la configuración y compilación del kernel Linux, pero es algo que me han preguntado recientemente. Por eso me he decidido a escribir este artículo corto para aclarar esta duda. Y es que siempre se habla de los módulos de seguridad SELinux y AppArmor, pero hay algo más allá de ellos.

Evidentemente SELinux y AppArmor son los más conocidos y usados por la mayoría de administradores de sistemas cuando quieren realizar prácticas de hardening para sus sistemas. Pero… ¿y si no te gusta ni uno ni otro?

Un poco de historia

En una de las cumbres sobre el kernel Linux de 2001 se propuso que SELinux se incluyese en la versión de desarrollo Linux 2.5. En ese momento, Linus Torvalds rechazaría incluir estas extensiones de seguridad en esa rama del kernel. Además, observó que existían otros proyectos de seguridad, a parte de SELinux.

Linus Torvalds emplazó a la comunidad a incluirlo como un módulo, y Crispin Cowan propuso la creación de LSM para proveer a los desarrolladores de lo necesario para que esos proyectos pudieran funcionar como módulos. Esa propuesta fue aceptada y una comunidad LSM se dedicaría los años siguientes a implementarlo.

Esta comunidad también recibiría contribuciones de otras empresas y colaboradores externos entre los que se puede destacar IBM, McAfee, SGI, la NSA, Immunix Corp, etc. Una vez estaba maduro, se incluiría como parte de Linux 2.6 a finales de 2003.

Tres años más tarde, algunos desarrolladores principales del kernel observaron que SELinux era el único módulo que se usaba ampliamente. LSM carecía de sentido, pero en la cumbre de este año Linus Torvalds rechazaría eliminar LSM para no favorecer a SELinux en detrimento de otros proyectos existentes.

Tras eso, otros módulos de seguridad adicionales como AppArmor, también fueron aceptados en la línea principal del kernel vainilla. Por tanto, ahora LSM tiene todo el sentido del mundo… De no haber tomado esa decisión, en la actualidad las opciones serían mucho más reducidas.

¿Qué es LSM?

LSM (Linux Security Modules) no es más que un framework que permite a los módulos de seguridad ser compatibles con el kernel y obtener lo que necesitan de él para realizar las restricciones o controles necesarios. Además, como has visto en la historia, se ha transformado en una medida adicional para evitar favoritismos hacia un módulo concreto.

Casi todo son ventajas en cuanto a LSM, solo que si no se tiene cargado ningún módulo de seguridad, éste no tiene carga cero. Es decir, supone una pequeña demanda de recursos adicionales de memoria y procesamiento. Uno de los motivos por los que no les gusta a algunos de los desarrolladores del kernel, entre otras razones…

Módulos de seguridad existentes

Si has descargado el código fuente de Linux desde kernel.org y has procedido a configurarlo, en el menú de configuración habrás podido observar que en el apartado de seguridad se pueden cargar diversos módulos del kernel. Entre ellos SELinux y AppArmor.

Estos módulos complementan al modelo DAC tradicional de UNIX mediante un sistema MAC (no lo confundas con la dirección MAC de redes). En este caso, los términos se refieren a:

• DAC (Discretionary Access Control): es una forma de control de acceso basada en propietarios y grupos. Se dice que es discrecional porque un sujeto podría transmitir sus permisos a otro sujeto. En definitiva, un sistema descentralizado, permitiendo que el propietario sea el que asigna los permisos.
• MAC (Mandatory Access Control): es un sistema de control de acceso basado en políticas. Las políticas son unas reglas que determinan lo que está permitido o no. Preceptivo en este caso refleja el hecho de que las políticas están centralizadas y no pueden ser sobrescritas por un sujeto. En este caso, los objetos y los sujetos solo tienen una serie de atributos, siendo las políticas las que se encargan de autorizar o denegar las acciones.

Entre estos módulos existe:

• AppArmor (Application Armor): es mi favorito, y para mi uno de los más fáciles de administrar y de los más seguros. Fue desarrollado inicialmente por Immunix (1998-2005), luego asumió el control SUSE (2005-2009) y después Canonical (2009-actualidad). Está licenciado bajo GPL y usa código C, C++, Python y scripts. Este módulo permite restringir las capacidades que tienen los programas mediante perfiles. Por ejemplo, podrías controlar los ficheros y directorios a los que tiene acceso un determinado programa, las capacidades de acceso a red, permisos, etc. Desde Linux 2.6.36 ya forma parte del kernel y ha sido adoptado como sistema principal de seguridad por multitud de distribuciones: Debian, Ubuntu, SUSE/openSUSE, Arch Linux, etc., así como derivados de éstas.
  • Ventajas: solidez y estabilidad, más transparente y sencillo de usar al usar control basado en path. Además, está soportado por defecto en multitud de distros, por lo que encontrarás mucha información para ayudarte con él.
  • Desventajas: probablemente algo menos seguro en comparación con SELinux.
• SELinux (Security Enhanced Linux): otro polémico módulo que ha sido muy criticado y rechazado por muchos. No porque sea inseguro, todo lo contrario, pero sí por haber sido desarrollado en 2000 por la NSA (Grupo de trabajo TRUSIX) junto con Red Hat (ahora propiedad de IBM). Fue escrito completamente en C y está licenciado bajo GPL, fusionándose con Linux en la serie 2.6. Admite diversas políticas de control de acceso y ha sido adoptado de facto en algunas distros como Fedora/RHEL/CentOS, así como otras distros y sistemas como Android.
  • Ventajas: buen diseño, más flexibilidad y más control sobre el aislamiento de procesos.
  • Desventajas: reglas extremadamente complejas y menos transparente en comparación con la «legibilidad» de AppArmor.

• TOMOYO: es otro módulo de seguridad para implementar MAC (Mandatory Access Control) similar a los anteriores, pero esta vez de origen nipón. Fue creado por NTT Data Corporation y lanzado por primera vez en 2003. Está licenciado bajo GPL y se ha terminado fusionando como parte del kernel. En este caso, se centra especialmente en el comportamiento del sistema, permitiendo que cada proceso declare comportamientos y recursos necesarios para lograr su propósito. De esa forma el administrador puede elegir qué puede hacer cada proceso y qué no.
  • Ventajas: completo MAC y centrado en comportamiento.
  • Desventajas: no cuenta con un gran soporte por parte de las distros importantes, lo que también implica menos información si te surgen dudas. Además, sus funcionalidades están algo limitadas, aunque existe una versión basada en éste llamada AKARI con más funcionalidad MAC.

• Smack (Simplified Mandatory Access Control Kernel): es otro módulo de control de acceso simplificado del kernel Linux. Permite la protección de datos y la interacción que hacen los procesos mediante unas reglas MAC similares a las de los anteriores módulos. Es muy simple, de hecho, ese es el objetivo principal de este desarrollo. Fue creado en 2008 por Casey Schaufler y también está bajo GPL. Se terminó fusionando con el kernel para Linux 2.6.25. Se ha usado en algunos proyectos como MeeGo, Tizen, etc., así como otros proyectos IoT, y desde 2016 se usa como sistema de seguridad principal para AGL (Automotive Grade Linux).
  • Ventajas: muy simple, por lo que la administración se hace sencilla. Ideal para IoT y dispositivos embebidos.
  • Desventajas: a lo largo de la historia se le han ido corrigiendo algunos problemas de seguridad encontrados y no es tan popular como SELinux y AppArmor, por lo que no encontrarás tanta ayuda en caso de dudas…

Por cierto otra pegunta que me suelen hacer algunos alumnos es si pueden tener AppArmor en, por ejemplo, Fedora, o SELinux en una distro que por defecto usa AppArmor como Ubuntu. La respuesta es sí, se puede usar sin problema alguno, pero lo que sí debes saber es que tienes que evitar tener ambos a la vez porque habrá conflictos…