# Seguridad Reforzada en Linux: SELinux y AppArmor En el mundo de la administración de sistemas Linux, la **seguridad** es primordial. Más allá de las herramientas de control de acceso discrecional (DAC) como los permisos de archivo tradicionales, los administradores profesionales recurren a mecanismos de seguridad más robustos, como los **Modelos de Control de Acceso Obligatorio (MAC)**. Este concepto es central en certificaciones avanzadas como **RHCSA** (particularmente el módulo **RH134**) y **LFCS**, que preparan a los profesionales para implementar seguridad a nivel empresarial. --- ### 🛡️ Introducción a los Modelos de Control de Acceso Obligatorio (MAC) El **Control de Acceso Obligatorio (MAC)** es un modelo de seguridad donde el sistema operativo (SO) restringe la capacidad de un sujeto (como un usuario o un proceso) para acceder o realizar alguna operación en un objeto (como un archivo o un dispositivo de red). A diferencia del **Control de Acceso Discrecional (DAC)**, donde el propietario del recurso establece los permisos, en MAC es el **administrador central** o la **política de seguridad del SO** quien determina el acceso, y el propietario no puede anular esas reglas. MAC ofrece un nivel de protección superior porque: 1. **Aísla procesos:** Si un proceso malicioso o comprometido intenta acceder a recursos fuera de su ámbito definido, el MAC lo bloquea inmediatamente, limitando el daño potencial. 2. **Define el comportamiento:** Se establecen reglas que definen *exactamente* lo que un proceso puede hacer (y nada más), adhiriéndose al principio de **mínimo privilegio**. Dos de las implementaciones de MAC más conocidas en el ecosistema Linux son **SELinux** y **AppArmor**. --- ### 🔴 SELinux: Security-Enhanced Linux (Énfasis RHCSA/RH134) **SELinux** (Security-Enhanced Linux) es el modelo MAC por defecto en distribuciones basadas en Red Hat (como RHEL, CentOS y Fedora), y su dominio es esencial para la certificación RHCSA. SELinux funciona asignando un **contexto de seguridad** a cada archivo y proceso, y luego utilizando **políticas** para definir cómo los contextos pueden interactuar entre sí. #### Modos de Operación de SELinux SELinux puede operar en tres modos principales, lo que permite a los administradores implementarlo de forma gradual y segura: 1. `Enforcing` (Obligatorio): 🚨 **Modo de máxima seguridad.** En este modo, SELinux aplica activamente la política de seguridad. Si una acción está prohibida por la política, **la niega** y registra un error (**audit log**). Este es el modo recomendado para sistemas de producción. 2. `Permissive` (Permisivo): ⚠️ **Modo de depuración/prueba.** SELinux **no aplica** la política de seguridad, lo que significa que **no niega** ninguna acción. Sin embargo, si una acción hubiera sido negada en modo *Enforcing*, el evento se registra en los *logs*. Esto es útil para probar nuevas políticas o depurar problemas de acceso sin interrumpir el servicio. 3. `Disabled` (Deshabilitado): 🚫 **Modo inactivo.** SELinux está completamente apagado y no realiza ninguna verificación ni registro de políticas. No se recomienda usar este modo a menos que sea estrictamente necesario, ya que desactiva una capa de seguridad crítica. #### Comandos Básicos de Gestión de SELinux Para la gestión diaria de SELinux, un administrador debe conocer los siguientes comandos: | **Comando** | **Descripción** | | --- | --- | | `sestatus` | Muestra el estado actual de SELinux: el modo, la política que se está cargando, y si está activado o no. | | `getenforce` | Muestra de forma concisa el modo actual de SELinux (ej. *Enforcing* o *Permissive*). | | `setenforce [0|1]` | Cambia el modo actual (`setenforce 0` cambia a modo *Permissive*, y `setenforce 1` a modo *Enforcing*). | | `semanage` | Herramienta avanzada para modificar la política de SELinux (ej. puertos, tipos de contexto de archivo, etc.). Requiere el paquete `policycoreutils-python-utils`. | | `chcon` | Cambia el contexto de seguridad SELinux de archivos/directorios. | | `restorecon` | Restablece el contexto de seguridad de un archivo/directorio a su valor predeterminado según la política. Esencial después de mover archivos a un nuevo directorio. | #### Ejemplo Práctico: El Servicio HTTPD (Apache) Para entender cómo funciona SELinux, veamos el ejemplo del servicio web **HTTPD** (Apache). SELinux asigna un **contexto de seguridad** (una etiqueta) a cada componente del servicio. La regla fundamental que se aplica aquí es: "*Un proceso que se ejecuta en el contexto httpd\_t sólo puede interactuar (leer, escribir, ejecutar, etc.) con objetos que tengan una etiqueta que la política permita específicamente, como httpd\_algo\_t.*" A continuación se muestran los contextos (tipos) típicos asignados a los componentes de HTTPD en RHEL, todos compartiendo la "*cabecera*" `httpd_`: | **Componente** | **Ruta de Archivo/Proceso** | **Contexto (Tipo) Típico** | | --- | --- | --- | | **Proceso (Dominio)** | `/usr/sbin/httpd -DFOREGROUND` | `httpd_t` | | **Binario Principal** | `/usr/sbin/httpd` | `httpd_exec_t` | | **Archivos de Configuración** | `/etc/httpd` | `httpd_config_t` | | **Directorios de Contenido** | `/var/www/html` | `httpd_sys_content_t` | | **Archivos de Logs** | `/var/log/httpd` | `httpd_log_t` | | **Startup Script (systemd)** | `/usr/lib/systemd/system/httpd.service` | `systemd_unit_file_t` | | **Puertos de Red** | `80/tcp`, `443/tcp` | `http_port_t` | El poder de SELinux reside en esta separación: * El proceso (`httpd_t`) tiene permiso para leer archivos con la etiqueta `httpd_config_t` y `httpd_sys_content_t`. * El proceso (`httpd_t`) tiene permiso para escribir en archivos con la etiqueta `httpd_log_t`. * **Implicación de seguridad:** Si un atacante compromete el servicio HTTPD, el proceso malicioso *aún* se ejecuta como `httpd_t`. Si ese proceso intenta leer un archivo sensible como `/etc/shadow` (que tiene el contexto `shadow_t`), **SELinux lo bloquea**. Aunque los permisos DAC (tradicionales de Linux) del archivo `/etc/shadow` pudieran permitir la lectura por el usuario `apache`, la política MAC de SELinux lo **obligará** a negarse porque la regla: "El proceso `httpd_t` puede leer el archivo `shadow_t`" no existe. --- ### 🛡️ SELinux vs. AppArmor: Comparación de MAC en Linux Mientras que SELinux es prominente en RHEL, **AppArmor** es el sistema MAC preferido en distribuciones como Ubuntu y SUSE. Ambos cumplen la función de Control de Acceso Obligatorio, pero tienen enfoques y arquitecturas diferentes, lo que a menudo genera debate sobre cuál es más "fácil" o "potente". | **Característica** | **SELinux (Security-Enhanced Linux)** | **AppArmor (Application Armor)** | | --- | --- | --- | | **Modelo de Seguridad** | Basado en **Tipos (Type Enforcement)**. El acceso se basa en el **contexto de seguridad** (Tipo) del proceso y del recurso. | Basado en **Rutas de Archivo (Path-Based)**. El acceso se define a través de rutas de archivos, de forma similar al DAC. | | **Complejidad** | Mayor. La asignación de contextos (Tipo, Rol, Usuario, Sensibilidad) es más detallada y requiere una curva de aprendizaje más pronunciada. | Menor. Las reglas son más intuitivas y legibles, basadas en rutas y permisos de estilo DAC (r, w, k, etc.). | | **Implementación** | Por defecto en **RHEL/CentOS/Fedora**. Integrado con las etiquetas de contexto del sistema de archivos. | Por defecto en **Ubuntu/SUSE**. Utiliza perfiles almacenados en el sistema de archivos. | | **Granularidad** | Muy alta. Permite un control extremadamente fino sobre cada interacción del proceso con el sistema. | Alta. Proporciona un buen nivel de control, pero puede ser menos detallado que SELinux en escenarios complejos. | | **Gestión** | Mayormente a través de comandos como `semanage`, `chcon`, `restorecon`, y manejo de booleanos. | Mayormente a través de herramientas de línea de comandos como `aa-status`, `aa-enforce`, y edición manual de perfiles. | | **Políticas** | Políticas grandes y monolíticas (ej. `targeted`) que cubren todo el SO, con reglas predefinidas para la mayoría de los servicios. | Perfiles discretos, a menudo generados por el administrador para aplicaciones específicas, con una filosofía de "menos es más". | **Conclusión:** Tanto SELinux como AppArmor proporcionan una capa de seguridad crucial para un sistema Linux. SELinux (RHCSA/RH134) es la opción más poderosa y granular, ideal para entornos de alta seguridad con administradores dedicados a dominar su complejidad. AppArmor (LFCS) ofrece una alternativa más sencilla de auditar y mantener para una protección robusta de las aplicaciones críticas. Dominar al menos uno de estos sistemas MAC es una habilidad esencial para cualquier administrador certificado. --- ## Invitación a la Comunidad 🚀 Este *post* forma parte de una serie dedicada a la arquitectura y administración de sistemas Linux. ¡Queremos construir el mejor recurso posible **con tu ayuda**! Te invitamos a: * **Clonar el Repositorio:** El código fuente de todos nuestros artículos está disponible en **GitHub**. * **Contribuir:** Si encuentras algún error, tienes sugerencias para mejorar la claridad de los conceptos o deseas proponer correcciones técnicas, no dudes en enviar un *Pull Request* (Solicitud de extracción). * **Comentar:** ¿Tienes una pregunta o un punto de vista diferente sobre algún concepto? Abre un *Issue* (Incidencia) en el repositorio para iniciar la discusión. Tu colaboración es vital para mantener este contenido preciso y actualizado. **¡Encuentra el repositorio y participa aquí:** [github.com/rootzilopochtli/introduccion-a-linux](https://github.com/rootzilopochtli/introduccion-a-linux)