Cambio en la forma de distribuir el código fuente de RHEL por parte de Red Hat
- En junio de 2023, Red Hat tomó la controvertida decisión de cambiar la forma de distribuir el código fuente detrás de Red Hat Enterprise Linux (RHEL)
- Esta decisión planteó muchas dudas sobre la viabilidad futura de reconstrucciones downstream de RHEL como Rocky Linux, AlmaLinux y Oracle Linux
- Desde entonces, cada distribución hizo anuncios para tranquilizar a la comunidad
- En muchas comunidades de código abierto, la decisión de Red Hat se interpretó como la influencia de una corporación codiciosa
- La gente dice que se mudó a Debian o que ya lo hizo, buscando un refugio
La importancia y la dificultad de la seguridad
- La seguridad es difícil, aburrida, desagradable y requiere mucho esfuerzo para hacerse bien
- Debian no está haciendo un esfuerzo suficiente para proteger a sus usuarios
Adopción de SELinux por parte de Red Hat y provisión de políticas predeterminadas
- Red Hat adoptó hace mucho tiempo el uso de SELinux, y fue más allá de simplemente activar la función en el kernel
- Hicieron el arduo trabajo de crear políticas SELinux predeterminadas para la distribución
- Estas políticas se entregan habilitadas por defecto en RHEL y ayudan a proteger muchos de los demonios y servidores más usados que se ejecutan por defecto en RHEL
- Apache, nginx, MariaDB, PostgreSQL, OpenSSH y otros están protegidos por las políticas SELinux que vienen con la distribución RHEL
Aplicación de políticas SELinux a contenedores
- La protección se extiende incluso a los contenedores
- Los contenedores se están convirtiendo cada vez más en el método preferido por los desarrolladores para desplegar software
- Es un error pensar que ejecutar algo en un contenedor es intrínsecamente seguro
- Los contenedores resuelven problemas de despliegue de software, no problemas de seguridad por sí mismos
- En distribuciones basadas en Red Hat se puede usar podman, una alternativa a Docker que ofrece la ventaja de ejecutar contenedores sin daemon y de manera completamente rootless
- Red Hat va un paso más allá y aplica políticas SELinux predeterminadas sólidas que aíslan a los contenedores del sistema operativo anfitrión y de otros contenedores
- Aplicar políticas SELinux a contenedores brinda protecciones reforzadas que ayudan a mitigar el riesgo de vulnerabilidades futuras aún desconocidas
El esfuerzo de Red Hat por ofrecer políticas SELinux predeterminadas
- Red Hat sabía que si no hacía el trabajo sobre estas políticas predeterminadas, los usuarios no adoptarían la tecnología y millones de servidores quedarían vulnerables
- SELinux es difícil, y su lenguaje de políticas y sus herramientas son complejos, oscuros y tan atractivos como llenar una declaración de impuestos
- Sin embargo, gracias al trabajo realizado por Red Hat, el uso de SELinux en RHEL es en gran medida transparente y ofrece beneficios reales de seguridad a los usuarios
El enfoque de Debian con AppArmor
- Debian es una pieza central de la comunidad de código abierto, conocida por su estabilidad y su amplia biblioteca de software
- Sin embargo, su framework de seguridad predeterminado deja mucho margen de mejora
- La decisión de habilitar AppArmor por defecto desde Debian 10 es un paso positivo para mejorar la seguridad, pero se queda corta al estar implementada a medias en todo el sistema
- La dependencia de Debian en AppArmor y su configuración predeterminada muestran un problema sistémico en su enfoque hacia la seguridad
- AppArmor puede ofrecer una seguridad sólida cuando está configurado adecuadamente, pero la configuración predeterminada de Debian no aprovecha ese potencial
Problemas de AppArmor en Debian
- Perfiles predeterminados limitados: Debian viene con un conjunto mínimo de perfiles AppArmor, lo que deja sin protección a muchos servicios importantes
- Postura reactiva frente a proactiva: el modelo de seguridad de Debian suele depender de que los usuarios implementen políticas más estrictas, en lugar de ofrecer una configuración segura por defecto
- Aplicación inconsistente: a diferencia de SELinux en sistemas Red Hat, AppArmor en Debian se aplica de forma parcial, lo que genera posibles brechas de seguridad
- Falta de recursos: como proyecto impulsado por la comunidad, Debian carece de los recursos para desarrollar y mantener políticas de seguridad integrales similares a las que ofrece Red Hat
Ejecución de cargas de trabajo en contenedores con Docker en Debian
- Ejecutar cargas de trabajo en contenedores con Docker en Debian es muy común
- Docker genera y carga automáticamente un perfil AppArmor predeterminado para contenedores llamado
docker-default
- Lamentablemente, este no es un perfil muy sólido en términos de seguridad y es demasiado permisivo
- Este perfil brinda cierto nivel de protección, pero deja expuesta una superficie de ataque considerable
Diferencias fundamentales entre AppArmor y SELinux
- La diferencia fundamental entre AppArmor y SELinux está en su enfoque del control de acceso obligatorio (MAC)
- AppArmor funciona con un modelo basado en rutas, mientras que SELinux usa un sistema de aplicación por tipos mucho más complejo
- Estas diferencias se vuelven especialmente evidentes en entornos de contenedores
- SELinux aplica tipos a todos los objetos del sistema (archivos, procesos, puertos, etc.)
- Cuando se inicia un contenedor en un sistema RHEL con soporte de SELinux, se le asigna de inmediato el tipo
container_t, un mecanismo estricto de control de acceso
- El tipo
container_t restringe eficazmente al contenedor, impidiéndole interactuar con objetos que no hayan sido etiquetados explícitamente para uso de contenedores
- SELinux no se detiene en la aplicación por tipos, sino que lleva el aislamiento de contenedores un paso más allá mediante etiquetas de seguridad multiclase (MCS)
- Estas etiquetas actúan como una capa adicional de separación que mantiene el aislamiento incluso entre contenedores del mismo tipo (
container_t)
- Cada contenedor recibe una etiqueta MCS única, creando un sandbox privado dentro del entorno más amplio de
container_t
El enfoque de AppArmor
- AppArmor no se preocupa por tipos ni categorías, y se centra en restringir las capacidades de programas específicos con base en perfiles predefinidos
- Estos perfiles especifican a qué archivos puede acceder un programa y qué acciones puede realizar
- Este enfoque es más simple de implementar y entender, pero no es tan granular ni tan consistente en todo el sistema como la aplicación por tipos de SELinux
- Las distribuciones Linux principales no distribuyen por defecto perfiles AppArmor integrales para todos los demonios comunes orientados a red
Impacto real
- En un entorno con SELinux, un contenedor comprometido enfrenta obstáculos importantes para acceder al sistema anfitrión o a otros contenedores, o para afectarlos, gracias a la doble barrera de la aplicación por tipos y las etiquetas MCS
- SELinux ofrece un aislamiento más fuerte, pero a costa de una mayor complejidad y una posible sobrecarga de rendimiento
- AppArmor ofrece un modelo de seguridad más simple y accesible que aun así puede ser muy efectivo cuando se configura adecuadamente
- Red Hat hizo el trabajo necesario para que SELinux y el uso de contenedores fueran fluidos y sencillos
- Al final, la elección entre Debian y Red Hat no es simplemente una elección entre influencia corporativa y desarrollo impulsado por la comunidad
- También es una elección entre un sistema que asume lo mejor y otro que se prepara para lo peor
- En el mundo altamente conectado de hoy, lamentablemente el pesimismo es indispensable
Opinión de GN⁺
- El cambio en la política de distribución del código fuente de RHEL por parte de Red Hat es polémico, pero desde la perspectiva de la seguridad puede ser una decisión razonable
- En una distribución Linux empresarial es indispensable ofrecer funciones de seguridad robustas como SELinux
- Sin embargo, el cambio de política de Red Hat puede afectar negativamente al ecosistema de código abierto, y el papel de distribuciones comunitarias como Debian será aún más importante
- Debian es conocido como una distribución amigable y flexible, pero necesita reforzar sus funciones de seguridad predeterminadas
- AppArmor no es tan potente como SELinux, pero si se configura correctamente puede ser una solución de seguridad efectiva
- A largo plazo, podría ser necesario desarrollar un nuevo framework de seguridad que combine las ventajas de SELinux y AppArmor
- La seguridad de contenedores es un tema muy importante en la era cloud-native, por lo que todas las distribuciones deberían dedicar más esfuerzo a este aspecto
2 comentarios
Es cierto que AppArmor es menos estricto que SELinux..
Pero es difícil decir que por eso su seguridad sea más débil.
SELinux es tan estricto que, cuando configuras un servidor, casi siempre lo terminan desactivando.
Y en el escritorio, la seguridad no es la principal preocupación de SELinux.
Se necesitan restricciones necesarias desde la UI o la experiencia de usuario, además de procedimientos adecuados para solicitar autenticación, y eso es un tema distinto al aislamiento de recursos como el de SELinux.
Por eso, la seguridad en escritorio, ya sea en la familia de Red Hat o en la de Debian, funciona basada en
polkit(PolicyKit), que se estandariza en freedesktop.Opiniones en Hacker News