A 02-07 vas veure una s on esperaves una x i et vaig prometre que l'entendries a fons en aquesta lliçó. Ha arribat el moment, i ve acompanyada de l'altra peça que has fet servir durant quatre mòduls sense preguntar-te res: sudo. Escrius sudo desenes de vegades al dia, però qui ha decidit que puguis fer-ho? On està escrit? Què passaria si la Marta et demanés que luis pogués reiniciar l'aplicació —només reiniciar-la— sense donar-li la màquina sencera? Aquesta lliçó respon a les tres preguntes i afegeix les eines que el model clàssic ugo/rwx no cobreix: capabilities, ACL i atributs immutables. Al final, operador podrà desplegar Tramontana amb una regla de sudoers escrita per tu, i el Luis llegirà els registres sense estar a adm.

1. Per què no es treballa com a root
2. su, su -, sudo -i i sudo -s comparats
3. sudo a fons: memòria cau, entorn i l'error de la redirecció
4. sudoers: sintaxi, visudo i regles segures
5. Traçabilitat: on queda l'empremta de sudo
6. Recuperar-se d'un sudoers trencat
7. SUID: UID real enfront d'UID efectiu
8. SGID en directoris: el bit del treball en equip
9. El bit sticky i /tmp
10. Capacitats: el substitut modern de SUID
11. ACL: permisos que ugo no sap expressar
12. Atributs estesos i immutabilitat
13. Cas Tramontana: la regla de sudoers del desplegament

Root no té permisos: root no té comprovació de permisos. El nucli, davant d'un procés amb UID efectiu 0, se salta la verificació sencera. Això significa tres coses:

• Un error és irreversible. rm -rf /opt/tramontana / amb un espai de més, executat com a operador, falla amb «Permission denied» a la segona ruta. Executat com a root, esborra el sistema.
• No hi ha traçabilitat. Si cinc persones comparteixen la contrasenya de root, auth.log dirà «root va fer X» i ningú no sabrà qui va ser. Amb sudo, dirà «operador va executar X com a root».
• No hi ha privilegi mínim. Qui necessita reiniciar un servei no necessita poder llegir /etc/shadow ni reformatar un disc.

Per això Ubuntu ve de fàbrica amb root sense contrasenya utilitzable (! a shadow, com vas veure a 05-01) i tota la feina administrativa passa per sudo.

El guionet de su - (i de -i) és el que marca la diferència: sense ell t'emportes les teves variables, els teus àlies i el teu PATH a una sessió amb UID 0, i aquest és justament el vector pel qual un PATH manipulat amb un ls fals acaba executant-se com a root. Si necessites una sessió de root, fes servir sudo -i. I com a norma general, cap de les dues: un sudo per acció deixa millor rastre que una sessió de root oberta mitja hora.

El que fa sudo en invocar-lo: comprova la teva identitat contra /etc/sudoers, et demana la teva contrasenya (no la de root), registra l'ordre, construeix un entorn nou i executa l'ordre amb la identitat de destinació.

La memòria cau de credencials guarda que ja t'has autenticat durant 15 minuts per terminal (timestamp_timeout, en minuts; 0 la desactiva i -1 la fa eterna, cosa que és mala idea). sudo -k la invalida ara mateix, sudo -v la renova sense executar res, útil al principi d'un script llarg.

Opcions que es fan servir a diari:

Per defecte env_reset esborra el teu entorn i secure_path imposa un PATH fix. És una protecció deliberada: sense ella, exportar LD_PRELOAD o alterar el PATH abans d'un sudo seria un ascens a root immediat. Aquesta és també la raó que sudo no trobi de vegades un binari teu de /home/operador/bin: no és a secure_path, i cal donar-ne la ruta absoluta.

I el clàssic que arrosseguem des del Mòdul 3:

No falla echo: falla la redirecció, que la fa el teu shell —que continua sent operador— abans que sudo arribi a executar-se. Les dues solucions correctes:

El fitxer és /etc/sudoers, però no s'edita: s'edita amb visudo, i les regles pròpies es posen en fitxers a part dins de /etc/sudoers.d/, que sudoers inclou amb @includedir. visudo bloqueja el fitxer contra edicions simultànies i, sobretot, valida la sintaxi abans de desar. Un sudoers amb un error de sintaxi deixa el sistema sense cap sudo funcional, i això és una emergència.

Els fitxers de /etc/sudoers.d/ han de tenir mode 0440, propietat root:root, i no portar punt ni acabar en ~ al nom, o sudo els ignora en silenci.

• El % davant del nom significa grup: per això pertànyer a sudo et dona poders, és aquesta línia.
• màquina permet distribuir el mateix sudoers a un parc sencer; en un servidor solt s'hi posa ALL.
• (root) és la identitat de destinació; (ALL:ALL) permet a més triar grup amb -g.
• NOPASSWD: evita demanar la contrasenya. Còmode per al que executa un script; perillós per a tota la resta.

sudoers admet ! per denegar, i és un parany:

Se salta de mil maneres. Si pots executar ALL, pots executar cp /bin/bash /tmp/sh && chmod u+s /tmp/sh, o simplement:

La regla d'or: una regla de sudo és una llista blanca. Enumera el que es permet; no intentis enumerar el que es prohibeix. I desconfia de qualsevol ordre que sàpiga executar altres ordres o editar fitxers arbitraris (vim, less, find, awk, tar --to-command, systemctl sense subordre fixa, qualsevol intèrpret).

Regles segures:

La mateixa informació és al journal (journalctl -t sudo, que veurem a 05-06). Els intents fallits es registren igual, i són el senyal d'alarma més barat que té un servidor.

Si necessites més, sudoers pot gravar la sessió sencera amb Defaults!SERVEI log_input, log_output i Defaults iolog_dir=/var/log/sudo-io; es reprodueix amb sudoreplay -l i sudoreplay ID. Compte: grava el que es teclegeja, incloses contrasenyes escrites per error, així que aquell directori és material sensible i la seva retenció ha d'estar acordada.

Si has desat un sudoers invàlid sense visudo, qualsevol sudo respon alguna cosa com >>> /etc/sudoers: syntax error near line 22 <<< i es nega a funcionar. Sortides, per ordre de preferència:

1. Una sessió de root encara oberta en una altra terminal: arregla-ho des d'allà. Per això convé tenir-ne una d'oberta mentre es toquen aquests fitxers.
2. pkexec, que fa servir polkit i no depèn de sudoers: pkexec visudo (requereix que existeixi una regla de polkit per al teu usuari, habitual en instal·lacions d'escriptori).
3. Mode de recuperació: reiniciar, triar Advanced options → recovery mode → root shell, tornar a muntar amb mount -o remount,rw / i executar visudo. El procediment complet és matèria de 07-01.

El costum que evita tot això: editar sempre amb visudo, i abans de tancar la sessió, comprovar en una altra terminal que sudo -l continua funcionant.

Tot procés porta dues identitats: l'UID real (qui l'ha llançat) i l'UID efectiu (amb qui es comproven els permisos). Normalment coincideixen. El bit SUID trenca aquesta igualtat: en executar un binari amb SUID, el nucli posa com a UID efectiu el del propietari del fitxer, no el de qui l'executa.

L'exemple canònic és passwd, que ha d'escriure a /etc/shadow (640 root:shadow) essent invocat per un usuari normal:

Aquella s al lloc de la x del propietari és SUID. Mentre corre, passwd és root, i el seu codi està escrit per fer exactament una cosa i res més.

Un SUID root propi és gairebé sempre una fallada de seguretat, perquè qualsevol descuit dins del programa —una crida a system(), un PATH heretat, un desbordament— es converteix en root per a qui l'invoqui. Un script de shell amb SUID ni tan sols funciona: Linux ignora el bit als intèrprets, precisament perquè és impossible d'assegurar.

Auditoria obligatòria en qualsevol servidor:

Guarda aquesta llista com a línia base. Qualsevol binari que aparegui després i no vingui d'un paquet és una alarma. -perm -2000 fa el mateix amb SGID.

En un executable, SGID és l'equivalent de SUID per al grup. Però el seu ús important és un altre: en un directori, SGID fa que tot el que es creï a dins hereti el grup del directori en lloc del grup primari de qui ho crea. És la peça que fa viable el treball compartit.

Sense SGID, si operador (grup primari operador) deixa una còpia a /srv/tramontana/backups, el fitxer pertany al grup operador i el luis no el pot llegir encara que tots dos siguin a tramontana. Amb SGID:

Grup tramontana sense haver-ho demanat: això és SGID. Aplica'l a tot l'arbre compartit i no només a l'arrel:

El bit SGID no arregla els permisos: si la teva umask és 027, el fitxer surt rw-r----- i el grup només llegeix. Perquè el grup també escrigui cal umask 007, o millor, una ACL per defecte (apartat 11).

/tmp és escrivible per tothom. Sense protecció addicional, qualsevol podria esborrar el fitxer temporal d'un altre, perquè el permís d'esborrat depèn del directori, no del fitxer. El bit sticky ho corregeix: en un directori amb sticky, només poden esborrar o reanomenar un fitxer el seu propietari, el propietari del directori i root.

La t final és el bit sticky (octal 1). És la raó que el mktemp dels teus scripts del Mòdul 4 sigui segur davant del veí, encara que continuï necessitant trap per netejar.

Resum dels tres bits:

Una S o una T majúscules a ls -l signifiquen que el bit especial està posat però falta la x corresponent: gairebé sempre és un error d'escriptura.

SUID és tot o res: dones root sencer per aconseguir una sola facultat. Les capabilities de Linux parteixen els privilegis de root en una quarantena de peces independents, i es poden concedir una a una.

El cas de manual: Tramontana vol escoltar al port 80, i els ports per sota de 1024 requereixen privilegi. En lloc de fer córrer l'aplicació com a root:

e és effective i p és permitted. Ara el binari obre el 80 essent svc-tramontana i no pot fer res més del que root podria. Altres d'habituals: cap_net_raw (per a un ping propi), cap_dac_read_search (llegir qualsevol fitxer: gairebé tan perillós com root, compte), cap_sys_time.

Advertiments reals: les capacitats són un atribut estès del fitxer, així que es perden en copiar, en reemplaçar el binari en un desplegament i en un sistema de fitxers que no les admeti. Si desplegar.sh substitueix el release, cal tornar-les a aplicar — o, millor, deixar que systemd ho faci amb AmbientCapabilities a la unitat, que és el que muntarem a 05-05.

El model clàssic té tres subjectes: propietari, grup, altres. La Marta demana una cosa que no hi cap: «que el Luis pugui llegir /var/log/tramontana per diagnosticar, però sense ficar-lo a adm, que dona accés a tots els registres del sistema». Amb ugo només podries canviar el grup del directori o obrir-lo a «altres». Amb ACL, dones exactament aquell permís a aquella persona.

Concedim lectura i recorregut a luis, i que ho hereti el que es creï després:

Aquell + al final dels permisos és la marca que hi ha una ACL; sense ell, ls -l et mentiria per omissió.

La màscara (mask::) és el sostre de permisos efectius de totes les entrades tret de user:: i other::. Si la màscara és r--, una entrada user:luis:rw- queda efectivament en r--, i getfacl ho indica amb un comentari #effective:r--. I aquí hi ha el parany: chmod g=... reescriu la màscara, de manera que un chmod -R 750 posterior pot anul·lar en silenci totes les teves ACL. Si fas servir ACL, revisa-les després de qualsevol chmod sobre aquella ruta.

Requisit: el sistema de fitxers ha d'estar muntat amb suport d'ACL, que a l'ext4 d'Ubuntu 24.04 ve activat de sèrie. I no oblidis que cp no copia les ACL tret d'amb -p o -a, ni tar tret d'amb --acls.

Per sota dels permisos hi ha una capa més: els atributs del sistema de fitxers. L'útil per a un administrador és i, immutable: el fitxer no es pot modificar, esborrar, reanomenar ni enllaçar, ni tan sols per root, fins que es retiri l'atribut.

És una xarxa de seguretat contra l'error humà i contra scripts massa entusiastes, no contra un atacant amb root (que el pot treure igual que tu). Un altre atribut útil és a (append-only), pensat per a fitxers de registre: s'hi pot afegir, no reescriure ni truncar. I un advertiment pràctic: un fitxer immutable trenca qualsevol automatisme que el toqui, inclosos apt i el teu propi desplegar.sh. Documenta-ho a l'HISTORIAL o ho pagaràs a les 4:20 de la matinada.

La Marta aprova els desplegaments, però qui els executa és operador, que avui té sudo complet per estar al grup sudo. L'objectiu: que pugui fer la seva feina —gestionar el servei i desplegar— sense root total, i que luis pugui consultar l'estat sense tocar res.

Detalls que no són decoratius:

• desplegar-segur és un embolcall propietat de root:root i mode 0755 a /home/operador/bin/. Si pertanyés a operador i fos escrivible per ell, la regla equivaldria a donar root complet: podria reescriure l'script amb /bin/bash a dins. Aquesta és la fallada més freqüent en concedir «només un script».
• Les subordres van fixes: systemctl a seques permetria systemctl edit, i d'aquí a un editor com a root hi ha un pas.
• El luis té només lectura i amb NOPASSWD, perquè ho crida des del seu tauler de diagnòstic. operador continua al grup sudo mentre duri la transició; l'objectiu a mitjà termini és treure'l i quedar-se només amb aquestes regles.

Avís de compliment. Una regla de sudo és una concessió de privilegi amb impacte directe en la seguretat del sistema i en l'accés a dades personals d'hostes (els registres i les còpies en contenen). Tota alta, canvi o retirada de regles ha de quedar documentada, amb data i autoritzant, i l'ha de revisar el responsable de seguretat o de compliment (RGPD) abans d'aplicar-se en producció. Revisa sudo -l -U usuari per a cada compte almenys una vegada al trimestre i en cada baixa de personal.

I les peces de l'apartat anterior aplicades al projecte:

• Editar /etc/sudoers amb un editor normal. Un error de sintaxi i et quedes fora: visudo sempre, i tingues una segona terminal oberta mentre edites.
• Fitxer mal anomenat o amb permisos incorrectes. sudo ignora en silenci els fitxers de /etc/sudoers.d/ que continguin un punt o no siguin 0440. Comprova-ho amb sudo -l -U usuari.
• Concedir un script que l'usuari pot editar. És root complet disfressat. L'objectiu d'una regla ha de ser root:root i no escrivible pel seu beneficiari.
• Fer servir comodins o ordres «que executen coses». systemctl, vim, less, find, tar, qualsevol intèrpret: tots tenen una via coneguda a shell. Fixa la subordre i els arguments, i no confiïs en ! per denegar: les llistes negres se salten sempre.
• Aplicar SGID només a la carpeta arrel d'un arbre compartit: els subdirectoris existents no l'hereten; fes servir find -type d -exec chmod g+s {} +.
• Perdre les capacitats en un desplegament. setcap viu al fitxer; si substitueixes el binari, desapareix. Declara-la a la unitat de systemd.
• Un chmod que s'emporta per davant les ACL en reescriure la màscara: després de qualsevol chmod sobre una ruta amb +, verifica-ho amb getfacl.
• Consell: guarda la línia base de find / -perm -4000 i de getcap -r / al costat de l'HISTORIAL. Comparar aquesta llista és l'auditoria més barata i més eficaç que pots fer.

1. Una regla mínima i correcta. El becari ha de poder reiniciar únicament tramontana.service i veure'n l'estat, sense contrasenya per a l'estat i amb contrasenya per al reinici. Escriu el fitxer, instal·la'l amb els permisos correctes, valida'l i demostra que sudo systemctl restart nginx li queda prohibit.
2. Auditoria de SUID. Troba els binaris amb SUID del sistema, comprova a quin paquet pertany cadascun i explica per què trobar /usr/local/bin/util amb SUID root seria una alarma.
3. ACL d'escriptura per a un tercer. La Marta necessita deixar un fitxer de tarifes a /srv/tramontana/backups/enviaments/ sense pertànyer al grup tramontana. Concedeix-li escriptura només en aquell subdirectori, amb herència, i verifica'n la màscara efectiva.

1.

En intentar el que està prohibit, com a becari:

Fixa't que la llista és blanca: no hem escrit cap prohibició, i tot el que no s'hi enumera queda fora per construcció.

2.

/usr/local/bin/util no pertany a cap paquet: ningú de la distribució no en respon, no s'actualitza amb apt i ningú no n'ha auditat el codi. Amb SUID root, qualsevol fallada seva —o qualsevol system() que hereti el PATH de qui l'invoca— lliura root a qualsevol usuari del sistema. Un binari així en un servidor de producció s'investiga com un possible compromís, no es «deixa per si de cas».

3.

u:marta:rwx sobre el directori li permet entrar-hi i crear; l'entrada default: fa que els fitxers que hi deixi neixin amb rw- per a ella. La màscara és rwx, així que els permisos efectius són els concedits: si valgués r-x, getfacl marcaria #effective:r-x i la Marta no podria escriure malgrat l'entrada. I recorda: un chmod g=rx posterior sobre aquell directori reescriuria la màscara i anul·laria el permís sense tocar l'entrada de la Marta.

S'ha acabat la màgia de sudo i la d'aquella s que arrossegaves des de 02-07. Saps que root no té permisos sinó absència de comprovacions, i per què això obliga a treballar amb privilegi mínim i traçabilitat; distingeixes su de su - i sudo -s de sudo -i per l'entorn que hereta cadascun; entens env_reset, secure_path i per què la redirecció de sudo echo falla; escrius regles de sudoers amb visudo, a /etc/sudoers.d/, amb rutes absolutes, arguments fixos i forma de llista blanca, sabent que les llistes negres se salten des de vim, find o awk; saps on queda la traça i com sortir d'un sudoers trencat.

I domines la capa de permisos que el model ugo no cobreix: SUID i la diferència entre UID real i efectiu, amb find -perm -4000 com a auditoria; SGID en directoris perquè un equip comparteixi fitxers de debò, aplicat ja a /opt/tramontana/shared/uploads i a /srv/tramontana/backups; el bit sticky que fa segur /tmp; les capacitats que substitueixen un SUID sencer per una sola facultat com cap_net_bind_service; les ACL amb què el Luis llegeix /var/log/tramontana sense entrar a adm, amb la seva màscara i el seu parany del chmod; i chattr +i per blindar /etc/tramontana/app.conf. A /etc/sudoers.d/tramontana hi ha una regla real, validada i documentada, que permet operar el servei sense repartir root.

El següent cap solt és el programari. Has instal·lat coses amb apt durant quatre mòduls sense preguntar-te d'on venien, qui les signa ni què passa si el motor de base de dades salta de versió major una nit qualsevol mentre dorms. A Gestió de Paquets veuràs les dues capes de Debian, dpkg i apt, l'anatomia d'un .deb, els dipòsits en format deb822 d'Ubuntu 24.04 amb les seves claus a /etc/apt/keyrings/, com fixar versions perquè la base de dades de Tramontana no es mogui sola, i el debat incòmode de si un servidor s'ha de reiniciar sol després d'una actualització de seguretat.