SELinux · Mandatory Access Control

Sin SELinux, un proceso que corre como root tiene acceso a todo. SELinux agrega MAC: cada proceso, archivo y puerto tiene un contexto de seguridad, y el kernel aplica reglas que ni root puede eludir. Así de simple.

Caso concreto: si alguien explota Grafana y escala a root, sin SELinux puede leer /etc/shadow. Con enforcing, el proceso tiene contexto container_t y el kernel le niega el acceso a archivos shadow_t, aunque se haya escapado a root. La política gana.

Enforcing bloquea. Permissive solo registra. Disabled apaga todo. SELinux tiene tres estados operativos. Este proyecto usa exclusivamente enforcing. Es el único modo que tiene sentido en un entorno que se presenta como hardening de producción.

SELinux en enforcing y booleanos para k3s activados. Cero configuración manual. Ansible lo aplica.

Defaults

selinux_mode: enforcing

selinux_booleans:
  - name: container_manage_cgroup
    state: true
  - name: virt_use_nfs
    state: true

Tasks

- name: Instalar policycoreutils-python-utils (semanage, getsebool)
  ansible.builtin.dnf:
    name: policycoreutils-python-utils
    state: present

- name: Verificar que SELinux esté en modo enforcing
  ansible.builtin.selinux:
    policy: targeted
    state: "{{ selinux_mode }}"

- name: Configurar booleanos de SELinux para k3s y servicios
  ansible.posix.seboolean:
    name: "{{ item.name }}"
    state: "{{ item.state }}"
    persistent: true
  loop: "{{ selinux_booleans }}"

- name: Mostrar estado de SELinux
  ansible.builtin.command:
    cmd: sestatus
  changed_when: false
  register: selinux_status

- name: Debug — estado de SELinux
  ansible.builtin.debug:
    var: selinux_status.stdout_lines

La tarea ansible.builtin.selinux es el core del rol. Asegura que la política targeted esté activa en modo enforcing. La política targeted es la estándar en RHEL — protege los servicios más comunes sin requerir reglas para cada proceso del sistema.

Los booleanos son interruptores de la política. Modifican lo que SELinux permite o bloquea para funcionalidades específicas.

Para verificar los booleanos manualmente después de correr el playbook:

Cada archivo, proceso y puerto tiene un contexto SELinux. Estos son los tres que aparecen una y otra vez en el lab.

Para ver el contexto de un archivo o directorio, se usa ls -Z. Para cambiarlo temporalmente, chcon. Para hacer el cambio persistente, semanage fcontext + restorecon.

Playbook terminado → confirmar que SELinux está enforcing y los booleanos activos.

Casi siempre es un booleano en false o un contexto incorrecto. Estos son los errores que van a aparecer con k3s.

Ubuntu trae AppArmor, Rocky trae SELinux. No son lo mismo y no se reemplazan. Tener experiencia con ambos marca diferencia.

¿Por qué el proyecto usa SELinux? Porque es el estándar en entornos RHEL, que dominan el mercado enterprise. Tener un proyecto con SELinux enforcing demuestra que se entiende la capa de seguridad que los entornos corporativos exigen.