Inseguridad de Debian / Sudo Null Noticias de TI
En junio de 2023, Red Hat tomó una controvertida decisión de cambiar la forma en que distribuye el código fuente de Red Hat Enterprise Linux (RHEL). Ha habido un acalorado debate en las redes sociales, dejando a muchos confundidos sobre las implicaciones de la decisión. Han surgido muchas preguntas sobre la viabilidad futura de las compilaciones secundarias de RHEL, que afectan a distribuciones como Rocky Linux, AlmaLinux, Oracle Linux y otras. Posteriormente, cada uno de ellos emitió declaraciones en un intento de tranquilizar a sus comunidades.
Sin embargo, muchos en la comunidad de código abierto vieron la decisión de Red Hat como un movimiento francamente astuto.
Cada vez más personas dicen que cambiarán (o ya lo han hecho) a Debian, buscando refugio de lo que ven como codiciosas influencias corporativas. Entiendo completamente este sentimiento. Sin embargo, hay un tema del que quiero hablar: la seguridad.
La triste verdad es que la seguridad es una tarea difícil. Es tedioso, frustrante y requiere mucho trabajo para hacerlo bien.
Debian no hace lo suficiente para proteger a los usuarios.
Hace mucho tiempo, Red Hat introdujo el uso de SELinux (Linux con seguridad mejorada). Y fueron más allá de simplemente incluir esta función en su núcleo. Han hecho un trabajo minucioso al crear políticas SELinux predeterminadas para su distribución.
Estas políticas vienen habilitadas por defecto en su distribución. Las políticas ayudan a proteger los diversos demonios que se ejecutan de forma predeterminada en RHEL, así como muchos de los demonios más populares que se usan comúnmente en los servidores.
Apache, nginx, MariaDB, PostgreSQL, OpenSSH, etc. están cubiertos por las políticas SELinux incluidas con las distribuciones RHEL.
La protección se extiende incluso a los contenedores. Los contenedores se están convirtiendo cada vez más en el método de implementación de software elegido por los desarrolladores, incluido yo mismo. Un error común es pensar que si ejecuta algo en un contenedor, es intrínsecamente seguro. Esto es completamente falso. Los contenedores por sí solos no resuelven el problema de seguridad. Resuelven el problema de la distribución de software. Dan una falsa impresión de seguridad a quienes los utilizan.
En distribuciones basadas en Red Hat, puede usar podman, una alternativa a Docker que le permite ejecutar contenedores sin un demonio (a diferencia de Docker) y brinda otros beneficios, como la capacidad de ejecutarse completamente sin raíz. Pero Red Hat va aún más allá y aplica políticas estrictas de SELinux de forma predeterminada, que separan el contenedor del sistema operativo host e incluso de otros contenedores.
Ha habido muchos ejemplos de cómo salir de un contenedor y acceder al sistema operativo host u otros contenedores. Aquí es donde entran en juego herramientas como SELinux. La aplicación de políticas SELinux a un contenedor crea un sarcófago reforzado para su aplicación que reduce el riesgo de futuras vulnerabilidades desconocidas. Y prácticamente no requiere ningún esfuerzo en RHEL.
Red Hat sabía que si no hacían el trabajo en estas políticas predeterminadas, sus usuarios simplemente no usarían la tecnología y millones de servidores seguirían siendo vulnerables. Porque seamos realistas, SELinux es complicado. El lenguaje y las herramientas de las políticas son engorrosos, poco intuitivos y casi tan hábiles como presentar la declaración de impuestos. Honestamente, es terrible de usar, si creas manualmente tus propias políticas.
Pero gracias al trabajo que ha realizado Red Hat, el uso de SELinux por parte de RHEL es en gran medida transparente y proporciona beneficios reales de seguridad a sus usuarios.
Enfoque debian
Debian, un bastión de la comunidad de código abierto, es venerado por su estabilidad y su extensa biblioteca de software. Soy fanático y hago donaciones al proyecto todos los años (¡tú también deberías hacerlo!), aunque no lo uso en un entorno de producción.
Sin embargo, su sistema de seguridad predeterminado deja mucho que desear. La decisión de Debian de habilitar AppArmor de forma predeterminada a partir de la versión 10 marca un paso positivo hacia una mayor seguridad, pero se queda corto debido a una débil implementación en el sistema.
La dependencia de Debian de AppArmor y sus configuraciones predeterminadas revela un problema sistémico con su enfoque de la seguridad. Si bien AppArmor es capaz de proporcionar una seguridad sólida cuando se configura correctamente, la configuración lista para usar de Debian no utiliza todo su potencial:
Perfiles restringidos predeterminados: Debian viene con un conjunto mínimo de perfiles de AppArmor, lo que deja muchos servicios críticos desprotegidos.
Postura reactiva en lugar de proactiva: El modelo de seguridad de Debian a menudo depende de que los usuarios apliquen políticas más restrictivas, en lugar de proporcionar una configuración predeterminada segura.
Uso inconsistente: A diferencia de SELinux en los sistemas Red Hat, que se aplica de manera uniforme en todo el sistema, AppArmor en Debian se aplica de manera poco sistemática, lo que genera posibles agujeros de seguridad.
Falta de recursos: Debian, como proyecto comunitario, no tiene los recursos para desarrollar y mantener políticas de seguridad integrales comparables a las proporcionadas por Red Hat.
Muy a menudo, los usuarios ejecutan cargas de trabajo en contenedores en Debian a través de Docker, que genera y carga automáticamente un perfil de AppArmor predeterminado para contenedores llamados docker-default. Desafortunadamente, este no es un perfil muy confiable desde el punto de vista de la seguridad; es demasiado permisivo;
Este perfil, si bien proporciona cierta protección, deja abiertas importantes superficies de ataque. Por ejemplo:
network,
capability,
file,
umount,
# Host (privileged) processes may send signals to container processes.
signal (receive) peer=unconfined,
# runc may send signals to container processes (for "docker stop").
signal (receive) peer=runc,
# crun may send signals to container processes (for "docker stop" when used with crun OCI runtime).
signal (receive) peer=crun,
# dockerd may send signals to container processes (for "docker kill").
signal (receive) peer={{.DaemonProfile}},
# Container processes may send signals amongst themselves.
signal (send,receive) peer={{.Name}},
deny @{PROC}/* w, # deny write for all files directly in /proc (not in a subdir)
# deny write to files not in /proc/<number>/** or /proc/sys/**
deny @{PROC}/{(^1-9),(^1-9)(^0-9),(^1-9s)(^0-9y)(^0-9s),(^1-9)(^0-9)(^0-9)(^0-9/)*}/** w,
deny @{PROC}/sys/(^k)** w, # deny /proc/sys except /proc/sys/k* (effectively /proc/sys/kernel)
deny @{PROC}/sys/kernel/{?,??,(^s)(^h)(^m)**} w, # deny everything except shm* in /proc/sys/kernel/
deny @{PROC}/sysrq-trigger rwklx,
deny @{PROC}/kcore rwklx,
deny mount,
deny /sys/(^f)*/** wklx,
deny /sys/f(^s)*/** wklx,
deny /sys/fs/(^c)*/** wklx,
deny /sys/fs/c(^g)*/** wklx,
deny /sys/fs/cg(^r)*/** wklx,
deny /sys/firmware/** rwklx,
deny /sys/devices/virtual/powercap/** rwklx,
deny /sys/kernel/security/** rwklx,Regla red Permite todas las llamadas al sistema de red sin restricciones.
Regla capacidadsin prohibiciones específicas, permite la mayoría de funciones de forma predeterminada.
Regla archivo otorga amplios permisos de archivos, basándose en reglas de denegación específicas para la protección.
AppArmor y SELinux
La diferencia fundamental entre AppArmor y SELinux es su enfoque de MAC (control de acceso obligatorio). AppArmor opera en un modelo basado en rutas, mientras que SELinux utiliza un sistema de control de acceso basado en tipos mucho más complejo. Esta diferencia se vuelve especialmente clara en entornos de contenedores.
SELinux aplica un tipo a cada objeto del sistema: archivos, procesos, puertos, lo que sea. Cuando ejecuta un contenedor en un sistema RHEL habilitado para SELinux, se le asigna inmediatamente un tipo contenedor_t – estricto mecanismo de control de acceso. Tipo contenedor_t aísla efectivamente el contenedor, evitando que interactúe con cualquier objeto que no esté explícitamente marcado para su uso por el contenedor.
Pero SELinux va más allá de la aplicación de tipos. Lleva el aislamiento de contenedores al siguiente nivel con etiquetas MCS (seguridad multicategoría). Estas etiquetas funcionan como una capa adicional de separación, asegurando que incluso los contenedores del mismo tipo (contenedor_t) permanecen aislados unos de otros. Cada contenedor recibe su propia etiqueta MCS única, creando lo que es esencialmente una zona de pruebas privada dentro de un entorno más amplio. contenedor_t.
A AppArmor, por otro lado, no le importan los tipos o categorías. Se centra en limitar las capacidades de programas específicos en función de perfiles predefinidos. Estos perfiles especifican a qué archivos puede acceder un programa y qué operaciones puede realizar. Si bien este enfoque es más sencillo de implementar y comprender, carece de la granularidad y la coherencia del sistema de la aplicación de tipos SELinux. Casi ninguna de las principales distribuciones de Linux distribuye perfiles completos de AppArmor para todos los demonios de red comunes de forma predeterminada.
Las implicaciones prácticas de estas diferencias son significativas. En un entorno SELinux, un contenedor comprometido enfrenta barreras significativas para acceder o influir en el sistema host u otros contenedores debido a las barreras duales del tipo de MCS y la aplicación de etiquetas.
Esto no significa que uno sea universalmente mejor que el otro. SELinux ofrece un aislamiento más fuerte, pero a costa de una mayor complejidad y una posible sobrecarga de rendimiento. AppArmor proporciona un modelo de seguridad más simple y accesible que aún puede resultar muy eficaz cuando se configura correctamente. El punto de mi argumento es que Red Hat ha hecho el trabajo para que el uso de SELinux y los contenedores sea fluido y fácil para sus usuarios. No tienes que resolverlo por tu cuenta.
En última instancia, 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 supone lo mejor y un sistema que se prepara para lo peor. Desafortunadamente, en el mundo interconectado de hoy, el pesimismo es necesario.
