Els permisos clàssics d’Unix, el conegut rwx d’usuari, grup i altres, han protegit els sistemes Linux durant dècades. Però tenen un límit estructural. Depenen de la bona voluntat del propietari de cada fitxer i, encara pitjor, no aturen un procés que ja s’executa amb privilegis. Si un servidor web compromès corre com a root, els permisos tradicionals no li impedeixen llegir /etc/shadow ni escriure on no toca. Per tapar aquest forat existeix el control d’accés obligatori, la segona capa de seguretat que porten integrada les distribucions modernes.
Què és el control d’accés obligatori (MAC)
El model habitual d’Unix s’anomena control d’accés discrecional (DAC): “discrecional” perquè cada usuari decideix, segons el seu criteri, qui accedeix als seus fitxers. El control d’accés obligatori (MAC, Mandatory Access Control) capgira aquesta lògica. Una política definida a escala de sistema estableix què pot fer cada procés, i ni tan sols root pot saltar-se-la sense canviar abans aquesta mateixa política.
La diferència és enorme. Amb MAC, un procés només toca exactament els recursos que la política li autoritza de manera explícita. Si un atacant es fa amb un dimoni, queda atrapat dins de les regles que confinen aquell dimoni concret, per molt que tècnicament sigui root. Confinar cada procés al mínim imprescindible és la base dels dos grans sistemes MAC del món Linux: SELinux i AppArmor.
SELinux: etiquetes i polítiques heretades de la NSA
SELinux (Security-Enhanced Linux) va néixer a l’Agència de Seguretat Nacional dels Estats Units (NSA), que va alliberar la primera versió com a programari lliure sota llicència GPL el 22 de desembre del 2000. El codi va entrar al nucli Linux principal amb la versió 2.6.0-test3, l’agost del 2003, recolzant-se en el marc de mòduls de seguretat LSM (Linux Security Modules).
El seu enfocament es basa en etiquetes (labels). SELinux assigna un context de seguretat a cada objecte del sistema: fitxers, processos, ports de xarxa, dispositius. La política decideix quines etiquetes poden interactuar amb quines. És un sistema d’un detall i una potència poc habituals, capaç d’aplicar Type Enforcement, control basat en rols (RBAC) i seguretat multinivell (MLS). Aquesta potència té la seva contrapartida: una corba d’aprenentatge ben costeruda. Quan alguna cosa no funciona, gairebé sempre és perquè a un fitxer li falta l’etiqueta correcta.
SELinux ve activat per defecte i en mode enforcing a Fedora i a Red Hat Enterprise Linux, i també a tota la família de RHEL: AlmaLinux, Rocky Linux i CentOS Stream. La política habitual, anomenada targeted, confina els dimonis més exposats —servidors web, bases de dades, serveis de xarxa— i deixa relativament lliures els processos d’usuari. És un equilibri assenyat entre seguretat i comoditat.
AppArmor: rutes en lloc d’etiquetes
AppArmor ofereix la mateixa protecció MAC però amb una altra filosofia: en comptes d’etiquetar cada objecte, defineix perfils basats en rutes del sistema de fitxers. Un perfil diu, per exemple, que /usr/sbin/nginx pot llegir un directori concret, escriure als seus registres i obrir determinats ports, i res més. El perfil s’associa al programa per la seva ruta, i això fa que els perfils siguin molt més fàcils de llegir i escriure que una política de SELinux.
La seva història es remunta a finals dels anys noranta, quan s’anomenava SubDomain dins de la distribució Immunix. Novell va comprar aquella tecnologia el 2005 i la va rebatejar com a AppArmor; des de la versió 2.6.36 del nucli forma part del cor principal de Linux. Avui és el sistema MAC per defecte a Ubuntu, Debian i openSUSE, precisament pel que té de senzill. Crear o ajustar un perfil amb eines com aa-genprof està a l’abast fins i tot d’administradors sense experiència prèvia en seguretat avançada.
SELinux contra AppArmor: quan tria cadascun
Aquí no hi ha guanyador absolut, sinó dos compromisos diferents. SELinux aposta pel control més exhaustiu possible: etiqueta tot el sistema i, ben configurat, ofereix un confinament difícil de superar, ideal per a entorns que exigeixen certificacions estrictes o aïllament d’alta seguretat. Ho pagues en complexitat i en un diagnòstic més laboriós.
AppArmor cedeix part d’aquest detall a canvi de claredat. Els seus perfils llegibles, lligats a rutes concretes, s’entenen d’un cop d’ull i es mantenen amb poc esforç. Per a molts servidors i estacions de treball, aquesta relació entre seguretat i simplicitat és just el que cal. Per això cada distribució tria l’un o l’altre segons el seu públic: la família Red Hat prioritza el rigor amb SELinux, mentre que les derivades de Debian aposten per l’accessibilitat d’AppArmor.
Conviuen amb la resta de la seguretat del sistema
Convé recordar que el MAC no substitueix les altres capes, s’hi suma. SELinux i AppArmor treballen al costat dels permisos clàssics, els namespaces, els cgroups i les capabilities del nucli per reforçar l’aïllament de contenidors i serveis. Tots dos blinden força la seguretat de tecnologies com Docker o Podman, perquè limiten el que un contenidor compromès podria fer sobre l’amfitrió.
El consell pràctic és clar: no desactivis el MAC de la teva distribució. La temptació de posar SELinux en permissive perquè “deixi de molestar” s’entén quan alguna cosa falla, però gairebé sempre amaga un problema d’etiquetatge que té solució. Aprendre a llegir els registres d’auditoria i a ajustar polítiques o perfils compensa amb escreix. On un sol servei compromès pot tombar una màquina sencera, el control d’accés obligatori és una de les millors defenses que Linux posa, de franc, a les teves mans.
