Portem cinc lliçons veient el mateix a cada ls -l i a cada stat sense explicar-ho: -rw-r-----, Uid: (990/meteora), Accés: (0640/-rw-r-----). Hem protegit 2026-08-31.dat del tall de llum amb el diari, de la fallada d'un disc amb RAID 1 i d'un bit capgirat amb un CRC per registre. Però no hem respost la pregunta més bàsica de totes: qui pot llegir aquell fitxer, i qui el pot esborrar?

La resposta és un model de dotze bits dissenyat el 1971 que continua sent, cinquanta anys després, la base del control d'accés de tots els sistemes UNIX. La seva virtut és la simplicitat; el seu perill, que aquella simplicitat amaga comportaments que sorprenen. Que els permisos d'un directori signifiquin coses diferents dels d'un fitxer. Que es pugui esborrar un fitxer que no es pot llegir. Que el permís es comprovi a tots els directoris del camí, no només al fitxer final. I que un programa executat per un usuari normal pugui, mitjançant un sol bit, modificar /etc/shadow.

Aquesta lliçó explica els dotze bits un a un, amb el perquè de cada comportament; afegeix les ACL POSIX per als casos que els dotze bits no cobreixen; presenta els atributs de fitxer, que protegeixen fins i tot de root; compara el model amb el de Windows; i acaba fixant i justificant els permisos exactes de tots els fitxers de Meteora, amb les ordres completes i una auditoria del que sol estar malament.

1. El model clàssic: usuari, grup i altres
2. Els bits r, w i x en fitxers i en directoris
3. Notació simbòlica i octal: chmod, chown, chgrp
4. umask: com es calcula el permís final
5. Els bits especials: setuid, setgid i sticky
6. Com comprova el nucli un accés, pas a pas
7. Llistes de control d'accés POSIX
8. Atributs estesos i atributs de fitxer
9. Comparació amb el model de Windows
10. Els permisos de Meteora, justificats
11. Errors greus i com auditar-los
12. Tancament del mòdul 4

Cada fitxer té al seu inode (04-01) dos identificadors numèrics i dotze bits de mode:

• UID del propietari: qui n'és l'amo. A Meteora, 990 (meteora).
• GID del grup propietari: quin grup té accés especial. També 990.
• Mode: dotze bits que diuen què pot fer cada classe d'usuari.

L'inode guarda números, no noms. La traducció a meteora la fan ls i stat consultant /etc/passwd i /etc/group; si esborres l'entrada de l'usuari, ls -l mostrarà 990 a seques i el fitxer continuarà sent seu.

Davant de qualsevol accés, el nucli classifica el sol·licitant en exactament una de tres classes:

I aquí hi ha la primera subtilesa, que produeix un desconcert clàssic:

Les tres classes són excloents i s'avaluen en aquell ordre. Si ets el propietari, s'apliquen només els bits d'usuari, encara que els de grup siguin més permissius.

El propietari no pot llegir el seu propi fitxer, mentre que qualsevol altre membre del grup meteora sí. No és una fallada: la classe es decideix primer i els permisos s'apliquen després. El propietari, això sí, sempre pot executar chmod sobre ell i arreglar-ho.

Cada classe té tres bits, r, w i x, cosa que dona els nou bits que mostra ls -l, més tres bits especials que veurem a l'apartat 5.

Aquí hi ha el cor de la lliçó, i el que més errors causa: els tres bits signifiquen coses diferents segons el tipus.

Recorda 04-02: un directori és un fitxer el contingut del qual és la llista de parells (nom, inode). Amb això, els tres significats deixen de ser arbitraris i es tornen inevitables:

• r = llegir el contingut del directori = llegir la llista de noms. Això és exactament el que fa ls.
• w = escriure al contingut del directori = afegir o treure entrades. Crear un fitxer és afegir una entrada; esborrar-lo és treure-la. Totes dues són escriptures al directori, no al fitxer.
• x = fer servir el directori per arribar a alguna cosa = poder resoldre un component del camí (04-02) i consultar l'inode associat a un nom que ja coneixes.

D'aquí surten les quatre conseqüències que cal interioritzar.

1. x sense r: pots entrar però no mirar. És el «directori fosc»:

Qualsevol pot accedir a /home/analista/informe.pdf si en sap el nom exacte, però ls /home/analista falla amb «Permís denegat». És la configuració clàssica dels directoris personals en servidors compartits i de l'arrel d'un servidor web: se serveix el que es demana, no s'enumera el contingut.

2. r sense x: pots veure els noms però res més. ls dades/ llista a.txt, però ls -l dades/ falla a cada entrada —perquè llegir l'inode de cada fitxer exigeix travessar el directori— i mostra una línia d'interrogants, -????????? ? ? ? ? a.txt. Aquells interrogants són la firma inconfusible d'r sense x, una combinació inútil que gairebé sempre és un error.

3. Es pot esborrar un fitxer que no es pot llegir ni escriure. Aquest és el comportament que més sorprèn, i ara és evident:

Esborrar no toca el fitxer. unlink (04-02) elimina una entrada del directori i decrementa el comptador d'enllaços de l'inode. L'operació és una escriptura al directori, i per això el permís que es comprova és w al directori, no al fitxer. Els permisos del fitxer són completament irrellevants.

És la raó per la qual existeix el bit enganxós, i per la qual un directori escrivible per tothom sense aquell bit és una bomba.

4. Canviar el contingut d'un fitxer no requereix permís al directori, i a l'inrevés. Els dos permisos són independents i protegeixen coses diferents: el del fitxer protegeix el seu contingut, el del directori protegeix el seu nom.

Els nou bits s'expressen de dues maneres equivalents. En octal, cada dígit codifica tres bits sumant 4 (llegir) + 2 (escriure) + 1 (executar/travessar): així, 6 és rw-, 5 és r-x i 7 és rwx. Els valors més habituals, amb el seu ús correcte:

Les ordres:

Tres precisions que eviten destrosses. L'octal és absolut i el simbòlic és relatiu: chmod 640 posa exactament aquells bits, mentre que chmod g+r n'afegeix un sense tocar els altres; en un chmod -R sobre un arbre, l'octal és perillós perquè aplica el mateix a fitxers i a directoris. La X majúscula és la solució a aquell problema, perquè significa «executar/travessar només si és un directori o si ja tenia algun x»: chmod -R u=rwX,g=rX,o= deixa els directoris navegables sense convertir en executables els fitxers de dades. I només el propietari i root poden executar chmod, mentre que només root pot executar chown per regalar un fitxer a un altre usuari: si un usuari normal ho pogués fer, esquivaria les quotes de disc i podria plantar fitxers comprometedors al compte d'un altre.

Quan un programa crea un fitxer, passa un mode a open() (04-04) —típicament 0666— o a mkdir —típicament 0777—. Però el fitxer no acaba amb aquells permisos, perquè el nucli aplica una màscara del procés: la umask.

Permisos finals = mode sol·licitat AND (NOT umask)

A la pràctica, és més fàcil veure-ho com una resta de bits: la umask diu quins permisos treure.

Fixa't en el detall important: la umask mai no afegeix el bit d'execució. Els programes demanen 0666 per a fitxers regulars precisament perquè un fitxer de dades mai neixi executable, per molt permissiva que sigui la umask. L'x d'un programa l'hi posa després el compilador o l'instal·lador amb un chmod explícit.

Els valors habituals i el que produeixen:

Meteora fa servir umask 027, i això explica tots els -rw-r----- i drwxr-x--- que portem veient des de 04-01. La justificació és exacta: l'ingestor crea 2026-09-01.dat i necessita que l'agregador i meteo-api —membres del grup meteora— el puguin llegir, però que cap altre usuari del sistema hi tingui accés. 027 dona precisament això, sense ni un sol chmod posterior.

Advertiment important: la umask per defecte és 022, que deixa els fitxers llegibles per tothom; amb ella, 2026-09-01.dat naixeria 644 i qualsevol usuari del servidor podria llegir les dades. La umask d'un servei es fixa amb UMask=0027 a la seva unitat de systemd (mòdul 7), no al .bashrc, perquè un dimoni no llegeix perfils d'intèrpret d'ordres. I s'hereta al fork (02-01), així que un script que la posi a 000 «perquè no hi hagi problemes» està creant fitxers 666 i directoris 777 sense que ningú se n'adoni.

Els dotze bits de mode són nou de permisos més tres d'especials, que en octal formen un quart dígit al davant:

Si el bit x corresponent no està posat, la lletra apareix en majúscula (S, T), i això gairebé sempre indica un error: un setuid sense execució no serveix de res.

El problema és concret. Un usuari normal ha de poder canviar la seva contrasenya, que és a /etc/shadow:

Només root hi escriu. Com pot aleshores un usuari qualsevol modificar-lo? La resposta és el bit setuid:

El recorregut complet, pas a pas:

1. L'usuari joan (UID 1000) executa /usr/bin/passwd; fork crea un fill amb UID real 1000 i UID efectiu 1000.
2. execve carrega el binari i veu el bit setuid. Aleshores fa el que és decisiu: posa l'UID efectiu al del propietari del fitxer, que és root (0).
3. El procés corre ara amb UID real 1000 (qui l'ha llançat) i UID efectiu 0 (amb quins privilegis actua). El nucli comprova els permisos amb l'efectiu.
4. passwd pot obrir /etc/shadow per escriure-hi. Però abans verifica acuradament la identitat: consulta l'UID real per saber qui és de debò, demana la contrasenya actual, i només permet canviar aquella línia.
5. En acabar, el procés mor i el privilegi desapareix amb ell.

Per què és perillós. Un binari setuid root és un programa que qualsevol pot executar amb privilegis de root, així que qualsevol fallada que tingui és una escalada de privilegis completa: un desbordament de memòria intermèdia, una injecció d'ordres, una variable d'entorn mal validada, un fitxer temporal amb TOCTOU (04-04), o simplement una opció que permeti executar un programa arbitrari. La història de la seguretat a UNIX és plena de vulnerabilitats en binaris setuid, i per això la regla és taxativa:

Com menys setuid, millor. Cada binari setuid root del sistema és una superfície d'atac, i cal poder justificar-los un per un.

Dos matisos que convé conèixer. El setuid s'ignora als scripts: Linux no el respecta en fitxers amb #!, perquè la finestra entre obrir el script i executar l'intèrpret permetia substituir-lo —un TOCTOU—. I nosuid en muntar (04-03) fa que el nucli ignori el bit en tot un volum, que és la raó de muntar així els volums de dades.

En un fitxer executable, setgid és l'anàleg de setuid amb el grup: el GID efectiu passa a ser el del fitxer. Es fa servir per donar accés a un recurs de grup sense donar root; /usr/bin/wall, per exemple, és setgid tty.

En un directori fa una cosa completament diferent i molt útil:

Un directori amb setgid fa que tot el que es creï a dins n'hereti el grup, en lloc del grup primari de qui ho crea. I els subdirectoris hereten també el mateix bit setgid, així que la propietat es propaga per tot l'arbre.

Sense setgid, si l'usuari analista (grup primari analista) crea un fitxer a /var/lib/meteora/, aquell fitxer serà del grup analista i l'agregador —que és del grup meteora— no el podrà llegir. Amb setgid:

Ara qualsevol fitxer creat allà dins pertanyerà al grup meteora, el creï qui el creï. És el mecanisme estàndard per a directoris compartits per un equip, i garanteix la coherència de grups sense dependre de la disciplina de cada usuari.

Recorda la conseqüència 3 de l'apartat 2: w en un directori permet esborrar qualsevol entrada, siguin quins siguin els permisos del fitxer. Ara aplica-ho a /tmp, que per definició ha de ser escrivible per tothom:

Sense la t, qualsevol usuari podria esborrar els fitxers temporals de qualsevol altre, o pitjor: esborrar el fitxer de sessió d'un servei i substituir-lo per un de propi, que és una via directa a la suplantació.

El bit enganxós (sticky bit) afegeix una restricció als directoris:

En un directori amb sticky, només poden esborrar o reanomenar una entrada: el propietari del fitxer, el propietari del directori, o root. El permís w del directori deixa de ser suficient.

S'aplica a tot directori escrivible per diversos usuaris: /tmp, /var/tmp, /dev/shm i qualsevol zona d'intercanvi compartida. I cal saber una cosa més: el sticky bit en fitxers no fa res a Linux modern. Antigament indicava «mantén aquest executable a la swap»; avui s'ignora.

Quan meteo-api executa open("/var/lib/meteora/lectures/2026-08-31.dat", O_RDONLY), el nucli fa això:

Els cinc punts que cal retenir d'aquest diagrama:

1. El permís x es comprova a TOTS els directoris del camí. És el que fa la resolució de camins de 04-02, component a component. Si a /var/lib/meteora li falta l'x per a la teva classe, tant se val que el fitxer final sigui rw-rw-rw-: no hi arribes. És la font número u dels «Permís denegat» incomprensibles, i es diagnostica en un segon amb namei -l, que mostra els permisos de cada component:

Quan algú no pot accedir a un fitxer, aquesta és la primera ordre que cal executar.

2. Les classes són excloents i l'ordre és fix. Propietari, després grup, després altres: la primera coincidència decideix i no es mira més. D'aquí el fitxer ----r--r-- que el propietari no pot llegir.

3. Compten tots els grups suplementaris. Un usuari pertany a un grup primari i a diversos de secundaris (id els mostra tots), i qualsevol serveix per entrar a la classe de grup. Avís important: els grups es llegeixen en iniciar sessió, així que un usermod -aG no afecta les sessions obertes ni els serveis ja arrencats.

4. Root se salta gairebé tot. L'UID efectiu 0 concedeix gairebé qualsevol accés, amb dues excepcions notables: no pot executar un fitxer sense cap bit x, i no pot escriure en un fitxer immutable (apartat 8).

5. Es comprova a open(), no a read(). Els permisos es verifiquen una sola vegada, en obrir. Si després algú executa chmod 000, el procés que ja el té obert continua llegint sense problemes, perquè el seu descriptor apunta a l'entrada de la taula de fitxers oberts (04-04) i no al nom ni al mode. Per tallar l'accés cal fer que tanqui el descriptor.

El model de tres classes té un límit estructural: només permet expressar permisos per a un usuari, un grup i la resta. Un cas real de Meteora el desborda de seguida: cal donar accés de només lectura a /var/lib/meteora/lectures a la usuària nuria, de l'equip d'anàlisi, sense ficar-la al grup meteora —que li donaria accés a tota la resta del servei, inclosa la configuració— i sense obrir els permisos d'«altres».

Amb els nou bits no es pot. Amb ACL POSIX, sí:

El resultat:

Els elements: user::rwx i group::r-x són el propietari i el grup propietari, equivalents als bits u i g de sempre; user:nuria:r-x i group:analistes:r-- són entrades anomenades, que donen permisos a un usuari o grup concret; other::--- són els altres; default:... és el que heretaran els fitxers creats aquí; i mask::r-x és la màscara, el màxim efectiu de totes les entrades anomenades i del grup.

La màscara és la part que confon tothom, i mereix una explicació clara. Els permisos efectius de qualsevol entrada anomenada són la intersecció d'aquella entrada amb la màscara. Si la màscara és r-- i l'entrada de nuria és rwx, nuria obté només r--, i getfacl ho assenyala explícitament:

Existeix perquè ls -l només té nou bits per mostrar. Quan hi ha una ACL, els bits de grup que mostra ls -l són en realitat la màscara, no els permisos del grup propietari. És un compromís deliberat perquè les eines antigues vegin alguna cosa raonable, i d'aquí surt el parany pràctic:

Un chmod g-w sobre un fitxer amb ACL modifica la MÀSCARA, i per tant retalla de cop els permisos efectius de totes les entrades anomenades. És la manera més habitual de trencar una ACL sense voler.

La regla és: quan un fitxer té + a ls -l, gestiona'n els permisos amb setfacl, no amb chmod.

Ordres essencials:

Dos advertiments operatius: les ACL requereixen que el sistema de fitxers les admeti —ext4 i XFS sí, i a les distribucions actuals estan activades per defecte—; i cal verificar que les eines de còpia les preservin, perquè cp -a, rsync -A i tar --acls sí que ho fan però un cp normal les perd en silenci, cosa que produeix fallades de permisos misterioses després d'una restauració.

A més dels permisos, un inode pot portar dues coses més.

Atributs estesos (xattr): parells clau-valor arbitraris organitzats en quatre espais de noms —system.* per a les ACL i l'ús intern del nucli, security.* per a les etiquetes de SELinux i les capabilities, trusted.* per a ús privilegiat, i user.* per a metadades d'aplicació, escrivible per qualsevol amb permís w—. Es manipulen amb setfattr -n user.origen -v "estacio-42" fitxer i getfattr -d fitxer. Les ACL de l'apartat anterior són atributs estesos (system.posix_acl_access), igual que les etiquetes de SELinux i AppArmor del mòdul 5.

Atributs de fitxer (chattr): indicadors a l'inode que modifiquen el comportament del sistema de fitxers. Són molt més potents del que sembla, perquè alguns vinculen fins i tot root:

Els dos primers són els interessants:

+a és especialment valuós per als registres de seguretat, perquè un atacant que aconsegueixi root no pot esborrar les seves petjades del registre: només pot continuar afegint-hi. És un complement natural de l'O_APPEND de 04-04, amb la diferència que aquell és un acord del programa i aquest l'imposa el sistema de fitxers.

Ara la lletra petita, per no crear falsa seguretat. Treure l'atribut requereix la capacitat CAP_LINUX_IMMUTABLE, que root té: chattr -i el desactiva en un segon, i un atacant amb root pot fer-ho. El seu valor real és doble: evita errors propis —un rm -rf mal escrit, un script de desplegament defectuós— i obliga a un pas deliberat i auditable abans de tocar alguna cosa crítica. No és una barrera contra un atacant decidit; és una assegurança contra accidents i una traça als registres, perquè l'aïllament fort davant de root és cosa de capabilities, SELinux i AppArmor, que es veuen al mòdul 5. I una conseqüència pràctica que mossega tothom: un fitxer amb +i trenca les actualitzacions automàtiques del gestor de paquets, de manera confusa. Documenta sempre què has marcat.

Convé conèixer l'altre model, perquè els conceptes es creuen constantment en entorns mixtos:

La diferència més important per a qui ve de Windows és la semàntica de l'esborrat: allà es controla amb un permís del fitxer, aquí amb el permís w del directori. És la causa de la majoria de les sorpreses en migrar, i explica per què el bit enganxós és necessari a UNIX i no té equivalent directe a Windows. L'altra és la denegació explícita: a Windows pots dir «tots els del grup Vendes poden llegir, excepte en Joan», mentre que a UNIX només es concedeixen permisos i l'única manera d'excloure algú és no incloure'l en cap classe que en tingui.

El judici equilibrat: el model de Windows és més expressiu i el d'UNIX més comprensible. I en seguretat, el que és comprensible té un valor propi: una ACL de Windows amb vint entrades heretades, denegacions i grups imbricats pot ser tan difícil d'auditar que ningú no sàpiga realment qui hi té accés. Els nou bits d'UNIX es llegeixen d'un cop d'ull.

Ara, l'aplicació completa. Aquests són els permisos exactes de tot el que compon el servei, amb el perquè de cada decisió.

Les ordres completes:

Les quatre decisions que de debò importen aquí, perquè són les que la gent fa malament:

1. La configuració pertany a root, no al servei. És l'aplicació directa del principi de mínim privilegi: si meteora fos el propietari de meteora.conf, un atacant que comprometés meteo-api podria reescriure la configuració —canviar camins, desactivar la validació, apuntar a un altre servidor— i esperar el reinici. Sent de root amb grup meteora i mode 640, el servei llegeix però no escriu. El mateix amb el binari: meteora no pot substituir /usr/bin/meteo-api per un troià.

2. Els secrets van en un fitxer a part. No perquè 640 no basti, sinó perquè separa dos cicles de vida: meteora.conf es pot versionar a Git, compartir en una incidència i copiar entre entorns; secrets.conf no. Barrejar-los garanteix que les claus acabaran en un repositori o en un tiquet. Es fa servir 0640 amb grup meteora —i no 0600— perquè el servei l'ha de llegir en arrencar.

3. Els registres tenen grup adm, no meteora. Així els administradors i el monitoratge llegeixen els registres sense pertànyer al grup del servei, que els donaria accés també a les dades i a la configuració. És separació de privilegis, no burocràcia.

4. Cap binari setuid. meteo-api escolta al port 8080 i no al 80, precisament per no necessitar privilegis. Si hagués de fer servir un port per sota de 1024, la solució correcta no és setuid root, sinó AmbientCapabilities=CAP_NET_BIND_SERVICE a la unitat de systemd, o un servidor intermediari invers al davant. Tornarem a les capabilities al mòdul 5.

Els quatre errors que més mal fan, i l'ordre que els troba.

chmod 777. És l'error emblemàtic. Significa «qualsevol usuari del sistema pot llegir, modificar i esborrar això», i a més marca els fitxers com a executables. Es posa gairebé sempre per sortir del pas davant d'un «permís denegat» que no s'ha entès, i deixa el forat obert per sempre.

-perm -0002 busca el bit d'escriptura per a «altres». Els únics resultats legítims són directoris amb bit enganxós (/tmp, /var/tmp, /dev/shm); tota la resta cal revisar-la. Davant d'un «permís denegat», el reflex correcte és namei -l, no chmod 777.

Secrets llegibles per tothom. Una clau privada amb permís de lectura per a «altres» és una clau compromesa; de fet, ssh es nega a fer servir una clau massa oberta, precisament per això.

chmod -R sobre un arbre mixt. Aquest mereix explicació perquè sembla innocu:

El segon és el cas instructiu. Aplica 644 a tot, inclosos els directoris, que es queden sense el bit x: ningú no els pot travessar, i tot l'arbre es torna inaccessible —l'efecte «interrogants» de l'apartat 2—. La manera correcta fa servir la X majúscula o separa per tipus:

Binaris setuid innecessaris. L'inventari cal revisar-lo i justificar-lo entrada per entrada. Una llista sanejada en té entre 10 i 20: passwd, su, sudo, mount, umount, ping, chsh, newgrp... Qualsevol binari setuid a /home, /tmp, /var o en un directori d'aplicació és una alarma vermella, i probablement una porta del darrere. Guardar una llista de referència i comparar-la és una detecció barata i eficaç:

Altres dues comprovacions que convé automatitzar són find / -xdev \\( -nouser -o -nogroup \\) i find / -xdev -type f -perm -0002 -perm -0111. Els fitxers orfes —l'UID dels quals no correspon a cap usuari— apareixen després d'esborrar un compte i són perillosos perquè el següent usuari que rebi aquell UID n'heretarà la propietat. I un fitxer alhora escrivible per tothom i executable és un vector d'atac de manual: qualsevol en substitueix el contingut i espera que algú l'executi.

Respondre a un «permís denegat» amb chmod 777. Gairebé sempre el problema és una x que falta en un directori del camí. Executa namei -l primer: et dirà en quin component exacte es trenca.

Aplicar chmod -R amb un valor octal. Tracta igual els fitxers i els directoris, i deixa els directoris sense x o els fitxers amb x. Fes servir u=rwX,g=rX,o= o separa amb find -type d i find -type f.

Creure que treure r i w a un fitxer impedeix esborrar-lo. Esborrar depèn del permís w al directori. Si vols protegir un fitxer de debò, protegeix el directori o fes servir chattr +i.

Oblidar que els grups es llegeixen en iniciar sessió. Després d'un usermod -aG, ni la teva sessió oberta ni els serveis en marxa veuen el grup nou. Reinicia la sessió o el servei.

Fer servir chmod sobre un fitxer amb ACL. Modifica la màscara i retalla els permisos efectius de totes les entrades anomenades: si veus un + a ls -l, fes servir setfacl. I en copiar, preserva les ACL amb cp -a, rsync -A o tar --acls, perquè un cp a seques les perd en silenci.

Deixar que un servei sigui propietari de la seva configuració i del seu binari. Si el comprometen, pot reescriure tots dos i persistir. Configuració i binari, de root; el servei només llegeix.

Posar setuid a un programa propi «perquè funcioni». Un binari setuid root és una escalada de privilegis esperant una fallada. Gairebé sempre hi ha una alternativa: una capability concreta, un grup, un sòcol amb permisos, o un servei separat.

Consell: namei -l i getfacl són les teves dues eines de diagnòstic —la primera recorre el camí component a component, la segona revela les ACL que ls -l només insinua amb un +— i audita periòdicament contra una línia base: la llista de setuid, els escrivibles per tothom i els orfes detecten tant errors propis com intrusions.

Crea una estructura de proves i demostra empíricament, mostrant la sortida de cada ordre: (a) que amb x però sense r en un directori pots llegir un fitxer el nom del qual coneixes però no llistar-lo; (b) que amb r però sense x obtens els interrogants d'ls -l; (c) que pots esborrar un fitxer d'un altre usuari, sense permís de lectura sobre ell, si tens w al directori; (d) que en activar el bit enganxós ja no pots. Explica a cada cas quin permís es comprova i sobre quin objecte.

La usuària nuria necessita llegir tots els fitxers de /var/lib/meteora/lectures, inclosos els que es creïn en el futur, sense pertànyer al grup meteora i sense que els permisos d'«altres» canviïn. Implementa la solució completa amb ACL, verifica que funciona, comprova què passa després amb un chmod g-w sobre el directori i explica per què. Compara-ho amb les dues alternatives dolentes —ficar-la al grup meteora, o posar o+r— indicant exactament a què tindria accés de més en cada cas.

Escriu un script d'auditoria que revisi: binaris setuid i setgid comparats amb una llista de referència; fitxers i directoris escrivibles per tothom que no tinguin bit enganxós; secrets a /etc llegibles per altres; fitxers orfes; i fitxers simultàniament escrivibles per tothom i executables. Per a cada troballa ha d'indicar el risc concret i la correcció proposada. Executa'l a la teva màquina i interpreta els resultats: digues quins són legítims i per què.

Solució 1

(a) x sense r — el directori fosc:

ls necessita r per llegir la llista de noms del directori, i no el té. cat només necessita x per travessar-lo fins a l'inode d'un nom que ja coneix. Es comprova r sobre el directori en el primer cas i x sobre el directori més r sobre el fitxer en el segon.

(b) r sense x:

ls llegeix la llista i funciona. ls -l necessita travessar el directori per llegir l'inode de cada entrada, i sense x no pot: d'aquí els interrogants. cat falla per la mateixa raó.

(c) Esborrar sense poder llegir, i (d) amb bit enganxós:

A (c), nobody no pot llegir un fitxer de root amb mode 600 però sí que el pot esborrar, perquè unlink és una escriptura al directori i hi té w: els permisos i el propietari del fitxer no hi intervenen en absolut.

A (d), amb sticky, només el propietari del fitxer (root), el propietari del directori o root poden esborrar. Fixa't en el detall: l'error ja no és EACCES («Permís denegat») sinó EPERM («Operació no permesa»), perquè la comprovació que falla no és la del bit w sinó la regla addicional del sticky. És exactament el mecanisme que protegeix /tmp.

Solució 2

El pas 3 és el que més s'oblida: sense l'ACL per defecte, nuria llegiria els fitxers d'avui però no els de demà, i la fallada apareixeria una setmana després sense causa aparent.

Què passa amb chmod g-w:

chmod sobre un fitxer amb ACL modifica la màscara. Si el chmod retallés els bits r o x de la classe de grup, la màscara baixaria i els permisos efectius de nuria es retallarien amb ella, encara que la seva entrada continuï dient r-x. Es restaura amb setfacl -m m::rx. La regla operativa: quan ls -l mostra +, gestiona els permisos amb setfacl.

Les dues alternatives dolentes:

L'ACL dona exactament l'accés demanat, a la persona demanada, sobre els fitxers demanats, i queda documentat a getfacl: és el principi de mínim privilegi aplicat amb l'eina adequada.

Solució 3

Interpretació dels resultats en una màquina sana. A [1] apareixen entre 10 i 20 binaris, tots a /usr/bin, /usr/sbin, /usr/lib o /bin —passwd, su, sudo, mount, umount, chsh, newgrp, pkexec, ping, i setgid crontab, wall, write—, i tots són legítims perquè necessiten privilegis que un usuari normal no té: modificar /etc/shadow, muntar sistemes de fitxers, obrir sòcols ICMP. Un setuid fora d'aquells directoris —a /home, /tmp, /opt o /var— és una alarma vermella.

A [2] l'esperable és cap resultat, perquè /tmp, /var/tmp i /dev/shm queden exclosos pel filtre ! -perm -1000; si hi apareix alguna cosa, gairebé sempre és un chmod 777 històric. A [3] ha d'estar buit, i qualsevol resultat exigeix dues accions i no una: corregir el permís i rotar la credencial, perquè cal assumir que ha estat llegida. A [4] sol haver-n'hi algun després de desinstal·lar programari o esborrar comptes, i es corregeix amb chown o esborrant el fitxer. I [5] ha d'estar buit sempre: és la combinació més perillosa de totes.

El que converteix això en una eina útil és executar-ho periòdicament i comparar-ho amb l'execució anterior: les troballes noves, i no la llista completa, són el que cal mirar. Automatitzar aquestes comprovacions i integrar-les amb l'auditoria del sistema és el tema d'Auditoria, Registres i Resposta a Incidents.

El model de permisos d'UNIX són dotze bits i dos números a l'inode, amb tres classes —usuari, grup i altres— que són excloents i s'avaluen en aquell ordre, d'aquí que un fitxer ----r--r-- no el pugui llegir el seu propi propietari. Els bits r, w i x signifiquen coses diferents en fitxers i en directoris, i aquella diferència deixa de ser arbitrària tan bon punt recordes que un directori és un fitxer amb una llista de parells (nom, inode): r és llegir aquella llista, w és afegir o treure entrades i x és travessar. D'aquí les quatre conseqüències: el directori fosc 0711, els interrogants d'r sense x, i sobretot que es pot esborrar un fitxer que no es pot llegir, perquè unlink escriu al directori i no toca el fitxer. Aquesta última és la raó que existeixi el bit enganxós, sense el qual /tmp seria inutilitzable.

Els permisos s'expressen en octal o simbòlic, i la diferència importa: l'octal és absolut i el simbòlic relatiu, així que un chmod -R 644 deixa els directoris sense x i trenca l'arbre sencer. La manera correcta de recórrer un arbre mixt és la X majúscula o separar amb find -type d i -type f. La umask decideix amb quins permisos neixen els fitxers restant bits del mode sol·licitat —666 per a fitxers, 777 per a directoris—, i mai no hi afegeix l'x: la 027 de Meteora és exactament el que produeix els 0640 i 0750 que portem veient tot el mòdul, enfront de la 022 per defecte que els deixaria llegibles per tot el sistema.

Els tres bits especials resolen tres problemes concrets. setuid explica com passwd escriu a /etc/shadow: execve posa l'UID efectiu al del propietari del binari, i deixa l'UID real per saber qui és de debò; és potentíssim i per això perillós, i nosuid en muntar (04-03) el desactiva per volum. setgid en un directori fa que tot el que es creï a dins n'hereti el grup i propaga el mateix bit als subdirectoris, que és el que garanteix la coherència de grup a /var/lib/meteora. I el sticky limita l'esborrat al propietari del fitxer.

La comprovació del nucli té cinc propietats que cal recordar: l'x s'exigeix a tots els directoris del camí —namei -l és el diagnòstic—, les classes són excloents, compten tots els grups suplementaris però només els que hi havia en iniciar sessió, root se salta gairebé tot llevat de l'execució sense cap x i l'atribut immutable, i es comprova a open(), de manera que un chmod 000 no talla qui ja té el fitxer obert. Quan les tres classes no basten, les ACL POSIX donen permisos a usuaris i grups concrets, amb ACL per defecte per a l'herència i una màscara que actua de sostre —i que un chmod descuidat retalla, trencant l'ACL sense avisar—. Els atributs chattr +i i +a afegeixen una capa que vincula fins i tot root: la primera evita accidents sobre fitxers crítics i la segona fa un registre al qual només es pot afegir. Enfront del model de Windows, més expressiu amb les seves ACE, la seva herència nativa i les seves denegacions explícites, el d'UNIX guanya en una cosa que en seguretat val molt: es llegeix d'un cop d'ull.

Aplicat a Meteora, tot es redueix a quatre decisions: dades 2750/0640 amb meteora:meteora; configuració i binari de root, perquè un servei compromès no es pugui reescriure a si mateix; secrets en un fitxer a part amb +i; registres amb grup adm per separar qui administra de qui executa; i cap binari setuid. I les auditories amb find —setuid contra una llista de referència, escrivibles per tothom sense sticky, secrets llegibles, orfes i escrivibles-i-executables— converteixen aquelles decisions en alguna cosa verificable en lloc d'en una intenció.

Val la pena mirar el recorregut complet, perquè el mòdul ha tingut un fil molt clar.

Vam començar amb l'abstracció (04-01): un fitxer és una seqüència de bytes amb nom, mida i propietari que el sistema col·loca on vol, i aquella idea resol de cop els set problemes que tindria qualsevol aplicació sobre el vector de blocs cru del mòdul 2, amb la mateixa estratègia que la memòria virtual. Vam veure els set tipus d'UNIX, vam disseccionar l'inode —i la seva absència més important, el nom—, vam recórrer la disposició física amb superbloc, mapes de bits i taula d'inodes, vam calcular el compromís de la mida de bloc i vam triar ext4 per a /var/lib/meteora amb arguments i no per costum.

El nom, que faltava, va arribar a 04-02: un directori és un fitxer amb parells (nom, inode), l'organització en graf acíclic explica per què no es permeten enllaços durs a directoris, la resolució de camins costa onze accessos en fred i gairebé cap amb la memòria cau de dentries, i unlink treu un nom en lloc d'esborrar un fitxer, d'on surten els enllaços durs, el fitxer esborrat que continua ocupant 17 GB i el truncate -s 0 /proc/<pid>/fd/N que ho cura.

Després vam acoblar l'arbre (04-03): particions GPT, LVM amb les seves instantànies per copiar en calent, i el muntatge pas a pas, amb UUID= en un fstab validat i les opcions nosuid,nodev,noexec que tanquen tres vectors pel preu de tres paraules. I sota de tot, el VFS amb els seus quatre objectes, que és el que permet que el mateix open() funcioni sobre ext4, sobre tmpfs, sobre /proc —que inventa els seus fitxers en llegir-los— i sobre NFS.

Amb el mapa complet vam passar a fer-lo servir (04-04): cinc crides al sistema, les tres taules que expliquen fork, dup i 2>&1, les dues capes de memòria intermèdia que cal distingir per no perdre dades, i els dos patrons que més escriuràs —la publicació atòmica amb temporal i rename(), i O_APPEND per als registres— més flock perquè no hi hagi dos agregador. Després vam baixar al disc (04-05): les quatre estratègies d'assignació fins als extents, els tres mecanismes que fan que un fitxer escrit 24 bytes cada 125 ms acabi contigu, el diari amb el seu bloc de commit atòmic, els tres modes d'ext4 amb ordered com a elecció raonada, i la distinció que tanca l'assumpte: coherència de metadades no és integritat de dades, RAID 1 detecta discrepàncies però no sap quina còpia és la bona, i de vegades la garantia l'ha de posar l'aplicació.

I aquesta última lliçó ha respost qui pot fer què.

Si el mòdul 2 responia com es reparteix un recurs escàs i el mòdul 3 com es coordinen diversos fluxos sobre una dada compartida, el mòdul 4 ha respost com es guarda alguna cosa perquè continuï existint demà. I la resposta ha tingut sempre la mateixa forma: una estructura al disc, una capa d'indirecció que la fa manejable, i una disciplina —de format, de sincronització o de permisos— que el programador ha de respectar.

Però fixa't en on ens deixa l'últim apartat. Hem tancat l'accés a /var/lib/meteora amb nou bits i una ACL, i hem suposat tota l'estona que l'UID 990 és meteora, que qui inicia sessió és qui diu que és, i que un procés que corre com a meteora fa el que meteora faria. Cap d'aquelles tres suposicions no és gratuïta. Com demostra algú que és qui diu que és? Per què root es pot saltar tots els permisos, i hi ha alguna manera que no pugui? Què impedeix que un meteo-api compromès, amb els seus permisos perfectament configurats, faci coses que ningú no va preveure? I com es detecta que una cosa així ha passat, quan l'atacant controla el sistema que escriu els registres?

Els permisos de fitxer són només una peça d'un model de protecció molt més ampli, que abasta subjectes, objectes, dominis de protecció, autenticació, privilegis mínims, control d'accés obligatori i auditoria. És el Mòdul 5: Protecció i Seguretat del Sistema, i comença a Principis de Protecció i Control d'Accés.