Arribes a l'última lliçó del mòdul amb un deute pendent. Portes sis lliçons veient cadenes com -rw-r----- i drwxr-xr-x a cada ls -l, escrivint sudo davant de certes ordres sense saber del tot per què, i acceptant que /etc/tramontana/app.conf pertany a root:tramontana sense poder explicar què implica això exactament. Aquesta lliçó salda aquest deute.

El model de permisos d'Unix té més de cinquanta anys i continua sent, amb diferència, el mecanisme de seguretat més utilitzat del planeta. És sorprenentment simple —nou bits i dos identificadors— i sorprenentment subtil: el mateix permís significa coses diferents en un fitxer i en un directori, i aquesta asimetria és la font de la majoria dels malentesos.

No és matèria opcional. Un servidor amb els permisos mal posats funciona perfectament fins al dia que algú llegeix un fitxer que no hauria de llegir, o n'esborra un que no era seu, o aconsegueix executar codi amb privilegis aliens. En acabar aquesta lliçó sabràs dissenyar els permisos d'un desplegament complet i justificar cada decisió, que és exactament el que s'espera d'un administrador de sistemes.

1. El model de seguretat d'Unix: usuari, grup, altres
2. Llegir la cadena d'ls -l caràcter a caràcter
3. Els tres permisos en fitxers i en directoris
4. Notació octal i notació simbòlica
5. chmod en totes dues notacions
6. chown i chgrp
7. Grups: per què el treball en equip no es resol amb «altres»
8. La màscara umask
9. Bits especials: SUID, SGID i sticky
10. Cas pràctic: els permisos de Tramontana Reserves

Tot fitxer a Linux té exactament un propietari i exactament un grup propietari. A partir d'aquí, el sistema divideix tothom en tres categories, i cadascuna té el seu propi joc de permisos:

Quan un procés intenta accedir a un fitxer, el nucli avalua en aquest ordre estricte:

Hi ha un detall en aquest diagrama que sorprèn i que cal interioritzar: la primera categoria que coincideix és la que s'aplica, i no es continua mirant. No és acumulatiu.

Conseqüència pràctica, i és contraintuïtiva:

Aquest fitxer pertany a operador, el propietari no té cap permís, i el grup té lectura i escriptura. Resultat: operador no pot llegir el seu propi fitxer, encara que pertanyi al grup tramontana. El nucli comprova primer si és el propietari, veu que sí, aplica --- i acaba. No arriba a mirar els permisos de grup.

És estrany trobar-ho a la pràctica, però explica el model millor que qualsevol exemple ben configurat: els permisos no se sumen, se seleccionen.

L'excepció és root, que se salta la comprovació sencera. Per això sudo cat funciona sobre qualsevol fitxer, i per això els permisos no protegeixen contra un administrador. Els detalls de sudo són la lliçó 05-02.

Darrere dels noms hi ha números. El sistema treballa amb UID i GID:

Els noms són una comoditat per a les persones; el nucli només veu números. Això importa en moure fitxers entre màquines: si copies amb tar -p un fitxer de l'UID 1001 a un altre servidor on el 1001 és una altra persona, el fitxer passa a pertànyer a aquesta persona.

La cadena -rw-r----- té 10 caràcters amb una estructura fixa:

Caràcter 1, el tipus. Els set que vas veure al Mòdul 1:

Caràcters 2 a 10, tres blocs de tres. A cada bloc, sempre en el mateix ordre: r, w, x. Un guionet significa que aquest permís no hi és.

Llegeix-la així, en veu alta fins que et surti sola:

-rw-r----- → «fitxer regular; el propietari llegeix i escriu; el grup només llegeix; els altres res».

Més exemples del mateix servidor:

I el cas especial:

lrwxrwxrwx: els permisos d'un enllaç simbòlic són sempre aquests i no signifiquen res. Com vas veure a la lliçó 02-06, els que s'apliquen són els del destí.

Aquí hi ha el punt on es perd més gent. Les mateixes tres lletres signifiquen coses diferents segons l'objecte.

Cadascuna de les tres files del costat dret mereix una demostració, perquè totes tres són contraintuïtives.

x en un directori s'anomena de vegades search permission. Sense ell no pots accedir a res del que hi ha a dins, encara que en sàpigues el nom exacte i encara que el fitxer interior et doni tots els permisos.

El fitxer té rw-rw-rw-: qualsevol el pot llegir. Però per arribar-hi, el nucli ha de travessar prova, i allà no hi ha x. Accés denegat.

I a l'inrevés, x sense r:

No pots veure què hi ha a dins, però sí accedir al que hi ha si en saps el nom exacte. És un directori «a cegues».

Això no és una curiositat: és un patró de seguretat d'ús habitual. Un directori 711 permet que un servei web serveixi /var/www/lloc/pagina.html sense que ningú pugui llistar el contingut del directori i descobrir quins altres fitxers hi ha. El mateix s'aplica a /home, que en molts sistemes és 711: els usuaris poden entrar al seu propi home, però no llistar els homes aliens.

Regla que cal memoritzar: per accedir a /a/b/c/fitxer, necessites x a /, a a, a b i a c, i després el permís adequat sobre fitxer. Una sola mancança de x en qualsevol punt del camí bloqueja tot el que hi ha a sota.

Pots llegir els noms, perquè els noms són al mateix directori. Però ls -l necessita consultar els inodes de cada entrada, i per a això cal travessar el directori. D'aquí aquella sortida amb interrogants: ls coneix el nom i res més.

r sense x en un directori és pràcticament inútil. A la pràctica, els directoris porten r i x junts o cap dels dos.

Aquest és el més important d'entendre, perquè contradiu la intuïció.

Has esborrat un fitxer de root que ni tan sols podies llegir.

L'explicació és coherent amb el que saps de la lliçó 02-06: esborrar un fitxer no és una operació sobre el fitxer, és una operació sobre el directori que el conté. rm elimina una entrada de la llista de noms del directori. I per modificar aquesta llista només cal w al directori.

Els permisos del fitxer controlen el seu contingut. Els permisos del directori controlen la llista de noms. Són dues coses diferents.

Resum de què permet w en un directori:

Aquest comportament és la raó de ser del sticky bit, que veuràs a l'apartat 9, i explica per què /tmp, on tothom escriu, no és un caos de gent esborrant-se fitxers.

Els nou bits de permisos s'expressen de dues formes.

Cada permís té un valor numèric i se sumen per bloc:

Un dígit per bloc, tres dígits en total: usuari, grup, altres.

Els que apareixen de debò en un sistema:

De simbòlic a octal, bloc a bloc:

D'octal a simbòlic, descomponent cada dígit:

Practica amb aquests fins que et surtin sense pensar:

I a l'inrevés:

Truc mental: 7 és tot, 6 és llegir i escriure, 5 és llegir i executar, 4 és només llegir, 0 és res. Amb aquests cinc cobreixes el 95 % dels casos reals.

stat et dona les dues notacions alhora, cosa que va molt bé mentre aprens:

La notació simbòlica es fa servir per modificar permisos sense tocar els altres. La seva gramàtica és:

Aquesta X majúscula és una joia poc coneguda i la veuràs en acció a l'apartat següent.

Es poden combinar diverses regles amb comes:

Quan fer servir cada notació:

-v i --changes mostren el que fa, útil per verificar:

I --reference copia els permisos d'un altre fitxer:

Sembla raonable i acaba de trencar tots els directoris de l'arbre. En treure'ls la x, ja no es poden travessar:

El problema és que fitxers i directoris necessiten permisos diferents: els fitxers normalment no han de ser executables, i els directoris sempre necessiten x.

La solució correcta és la X majúscula:

X aplica x només als directoris i als fitxers que ja tenien algun bit d'execució. Els fitxers de dades no es tornen executables; els directoris conserven la seva capacitat de ser travessats. És exactament el que vols en el 100 % dels casos recursius.

L'alternativa clàssica, si prefereixes separar explícitament, fa servir find (lliçó 03-03):

Apareix en centenars de respostes de fòrums com a remei per a «permission denied». Mereix una explicació seriosa de per què està malament, perquè l'argument «és insegur» a seques no convenç ningú que tingui pressa.

1. No arregla el problema, l'emmascara. Si alguna cosa donava «permission denied», hi havia una raó: un usuari equivocat, un grup mal assignat, una x que falta en un directori del camí. 777 fa que el símptoma desaparegui sense que sàpigues quina era la causa. Tornarà a aparèixer en un altre lloc.

2. Qualsevol usuari del sistema el pot modificar. I en un servidor hi ha més usuaris dels que et penses: comptes de servei com www-data, nobody, postgres. Si un atacant compromet el servei web —que no té privilegis— i la teva aplicació és 777, la pot reescriure sencera. Li has donat execució de codi com l'usuari que executa l'aplicació.

3. Amb -R sobre directoris, és pitjor. Els directoris 777 permeten a qualsevol esborrar i substituir fitxers que no són seus, pel que vas veure a l'apartat 3. Un atacant pot reemplaçar un binari pel seu.

4. Marca els fitxers com a executables. Un .conf o un .csv amb permís d'execució és un senyal d'alarma per a qualsevol auditoria, i en alguns servidors web una configuració desafortunada pot fer que un fitxer executable s'executi en comptes de servir-se.

5. És pràcticament irreversible. Després d'un chmod -R 777 /var, no hi ha manera de saber quins permisos tenia cada fitxer. En alguns casos cal reinstal·lar paquets per recuperar-los.

El diagnòstic correcte quan alguna cosa dona «permission denied»:

namei -l mostra els permisos de cada component de la ruta, i és l'eina que resol el cas més freqüent: el fitxer està bé, però un directori intermedi no et deixa passar. En aquest exemple, ruta és drwxr-x--- i pertany a root:root: aquí hi ha el bloqueig.

chown canvia el propietari, chgrp el grup:

Formes de chown:

Opcions:

Important: chown requereix root. Un usuari normal no pot regalar un fitxer a un altre:

La raó és concreta: si poguessis, podries burlar les quotes de disc creant fitxers enormes i assignant-los a un altre. I podries crear un fitxer amb SUID i regalar-lo a root, cosa que seria un forat de seguretat immediat.

chgrp sí que ho pot fer un usuari normal, però només si és membre del grup destí:

operador és membre de sudo, així que pot; no és membre d'adm, així que no.

--reference és molt pràctic per replicar la propietat d'un fitxer model:

I -h importa amb enllaços:

Com que el propietari d'un symlink és irrellevant per al control d'accés, -h es fa servir poc; però convé saber que sense -h, chown sobre un enllaç toca el destí, cosa que pot tenir conseqüències inesperades en recórrer un arbre amb -R.

Cada usuari té un grup principal (el dels seus fitxers nous) i pot pertànyer a diversos grups secundaris.

A Ubuntu, cada usuari té per defecte un grup propi amb el seu mateix nom (esquema UPG, User Private Group). El motiu és que permet treballar amb una umask més permissiva de manera segura: com que el grup de l'usuari només el conté a ell, donar permisos de grup no exposa res.

Consultar els grups del sistema:

La Marta planteja l'escenari real: en Luis Ferrer necessita poder llegir els registres de l'aplicació i escriure al directori de desplegaments; en el futur s'incorporarà una altra persona amb les mateixes necessitats. Com es resol?

Opció incorrecta: donar permisos a «altres».

Què has fet realment: has donat aquests permisos a tots els usuaris del sistema. No només a en Luis, sinó a www-data, a nobody, a qualsevol compte de servei i a qualsevol compte que es creï en el futur. Si un atacant compromet un servei sense privilegis, té accés als teus registres (que contenen noms d'usuari i patrons d'ús) i pot escriure al teu directori de còpies.

I per gestionar-ho: si demà vols treure l'accés només a en Luis, no pots. «Altres» no distingeix persones.

Opció correcta: un grup compartit.

Avantatges concrets:

La regla és absoluta: en un sistema multiusuari, l'accés compartit es resol amb grups. El permís d'«altres» es fa servir per al que de debò ha de ser públic, i en la majoria dels casos correctes val 0.

Un detall que sorprèn i que cal conèixer: els grups d'un procés es determinen en iniciar la sessió. Si t'afegeixen a un grup mentre tens la sessió oberta, el teu shell no ho veu:

Cal tancar la sessió i tornar a entrar (o fer servir newgrp tramontana per a la sessió actual). És una font clàssica de «li he donat permisos i continua sense funcionar».

Compte també amb usermod -aG: la -a és obligatòria. Sense ella, usermod -G tramontana operador substitueix tots els grups secundaris per aquest, cosa que trauria operador del grup sudo i el deixaria sense poder administrar el sistema. És un error que es comet una vegada a la vida.

Quan crees un fitxer, no en tries els permisos: els posa el sistema. La umask és la màscara que decideix quins es treuen.

Els valors de partida estan fixats pel nucli:

La umask es resta d'aquests valors. Més exactament, s'aplica una operació de bits que elimina els permisos marcats a la màscara.

Càlcul amb umask 022:

Comprovació:

Càlcul amb umask 027:

Comparativa de les màscares habituals:

Un matís tècnic important: la umask treu bits, mai no n'afegeix. Per això dir «es resta» és una simplificació útil però no exacta. Amb umask 022 i permisos base 666, el resultat és 644. Però si un programa demana crear un fitxer amb permisos 600 explícitament, la umask no el pujarà a 644: el resultat serà 600. La umask només pot ser més restrictiva que el que es demana.

Un altre matís: un dígit senar a la umask sobre fitxers no té efecte visible, perquè els fitxers neixen sense x de totes maneres. umask 023 i umask 022 produeixen fitxers idèntics, però directoris diferents (754 enfront de 755).

On es defineix la umask:

Els serveis de systemd tenen la seva pròpia directiva UMask= al seu fitxer d'unitat, i no hereten la del teu shell. Ho veuràs a la lliçó 05-05.

Recomanació per a srv-tramontana: umask 027 per als comptes administratius. Amb dades d'hostes al sistema, el valor per defecte que qualsevol usuari pugui llegir els fitxers nous és massa permissiu. Amb 027, tot el que creïs neix sense accés per a «altres», que és el principi de mínim privilegi aplicat des de l'origen.

A més dels nou bits, n'hi ha tres més. Aquí només n'aprendràs a reconèixer-los quan els vegis i què fan en una frase. El seu estudi a fons, amb les seves implicacions de seguretat i el seu ús correcte, és la lliçó 05-02.

Aquesta s on hauria d'anar la x de l'usuari és el bit SUID.

El problema que resol: les contrasenyes es guarden xifrades a /etc/shadow, que és -rw-r----- de root:shadow. Un usuari normal ni tan sols el pot llegir. Però ha de poder canviar la seva pròpia contrasenya, i això implica escriure en aquest fitxer.

Amb SUID, quan operador executa passwd, el procés corre com a root —el propietari del programa— i pot escriure a /etc/shadow. El programa està escrit per permetre únicament canviar la contrasenya pròpia.

Això és també la raó que els programes SUID siguin l'objectiu preferit dels atacants: una fallada en un binari SUID de root és una escalada de privilegis directa. Per això n'hi ha pocs, estan auditats, i trobar-ne un d'inesperat en un servidor és motiu d'alarma.

La s a la posició de la x del grup. En un directori, SGID fa que tot el que es creï a dins hereti el grup del directori, en comptes del grup principal de qui el crea.

Per què importa per a Tramontana: sense SGID, si en Luis crea un fitxer al directori compartit, el grup serà luis i operador no hi podrà accedir encara que tots dos siguin a tramontana. Amb SGID, el fitxer neix amb grup tramontana i l'equip pot treballar. És la peça que fa que un directori compartit funcioni de debò.

La t al final. /tmp és 777: tothom hi escriu. Pel que vas aprendre a l'apartat 3, això significaria que qualsevol pot esborrar els fitxers temporals de qualsevol, inclosos els de processos del sistema.

El sticky bit ho corregeix: en un directori amb aquest bit, només el propietari del fitxer (o del directori, o root) el pot esborrar o reanomenar. Pots crear els teus fitxers, però no tocar els aliens.

Una subtilesa que apareix als exàmens de certificació i que convé reconèixer:

Una S o una T majúscula sol indicar un error de configuració: has posat un bit especial sobre alguna cosa que no es pot executar ni travessar, així que no farà res útil.

Consultar els tres amb stat, on apareixen com un quart dígit:

4755 i 1777: el primer dígit són els bits especials.

Repeteixo la frontera: com i quan fer servir aquests bits, els seus riscos, com auditar els binaris SUID d'un sistema i com es relacionen amb sudo és matèria de la lliçó 05-02. Aquí només necessites reconèixer-los en un ls -l i no espantar-te.

La Marta et demana un informe amb el disseny de permisos del desplegament i la seva justificació. Anem ruta per ruta.

El punt de partida és el principi de mínim privilegi: cada compte té exactament els permisos que necessita per a la seva funció, i ni un més.

Actors del sistema:

Directoris 750, fitxers 640, executable 755.

Justificació:

• Propietari root: el servei no ha de poder modificar el seu propi codi. Si un atacant compromet l'aplicació explotant una fallada, no pot reescriure l'executable per persistir al sistema. Aquesta és la decisió més important de tot el disseny.
• Grup tramontana amb r-x: l'equip pot llegir el codi i travessar els directoris per diagnosticar.
• Altres sense res: cap compte de servei aliè no ha de veure el codi de l'aplicació.
• u=rwX,g=rX al recursiu: els directoris reben x i els fitxers de dades no, gràcies a la X majúscula.

640, i el directori 750.

Justificació:

• Conté la contrasenya de la base de dades. Amb el 644 habitual de /etc, qualsevol usuari del sistema la podria llegir. Això inclou www-data i qualsevol compte compromès. És la diferència entre un incident contingut i una filtració de la base de dades completa.
• El servei només necessita llegir, mai escriure. Sense w per al grup.
• El directori també 750: de res no serveix protegir el fitxer si el directori permet llistar i travessar. Recorda l'apartat 3: calen les dues coses.
• Cap còpia .bak no pot quedar amb permisos més laxos. Aquesta és una fallada real i freqüent: es copia la configuració a app.conf.bak i la còpia neix amb la umask del moment, potser 644. Es protegeix l'original i es deixa el secret exposat a la còpia. Verifica sempre els permisos de les teves còpies de seguretat.

cp -p preserva els permisos, així que la còpia neix igual de protegida. Sense -p hauria nascut amb la umask, que és just el que cal evitar aquí.

Directori 750, fitxers 640.

Justificació:

• El propietari és el compte de servei, perquè és qui ha d'escriure als registres. És l'única ruta del desplegament on el servei necessita permís d'escriptura.
• El grup adm és la convenció de Debian i Ubuntu per a «qui pot llegir els registres del sistema». Encaixa amb la resta de /var/log.
• Altres sense res, i això és important: acces.log conté noms d'usuari, adreces IP i patrons d'activitat. És informació que ajuda un atacant a preparar el pas següent, i que a més pot constituir dada personal.
• El directori necessita w per al servei perquè logrotate i la mateixa aplicació hi crearan fitxers nous.

2770: 770 més el bit SGID.

Justificació:

• El grup necessita escriure, perquè els operadors generen i roten còpies.
• El SGID (2) fa que tot el que es crea a dins hereti el grup tramontana. Sense ell, una còpia creada per en Luis tindria grup luis i la resta de l'equip no la podria gestionar. És el cas d'ús de l'apartat 9, aplicat.
• Altres, res. Les còpies contenen tot: el codi, la configuració amb credencials i, segons què es copiï, dades d'hostes. Un directori de còpies llegible és una manera de donar accés a tota la resta saltant-se els permisos que acabes de dissenyar.

Verificació final del disseny:

Aquest disseny és un exercici didàctic sobre dades fictícies. En un entorn real, reserves.csv i els registres d'accés contenen dades personals d'hostes: noms, dates d'estada i patrons de comportament. Això els sotmet al RGPD i a la normativa de protecció de dades.

En un desplegament real:

• El disseny de permisos l'ha de revisar el responsable de seguretat de la informació o el delegat de protecció de dades abans de passar a producció, no l'administrador pel seu compte.
• Pot ser obligatori xifrar les dades en repòs, no només restringir l'accés mitjançant permisos.
• Els registres d'accés a dades personals poden haver-se d'auditar i conservar durant un termini determinat.
• Els permisos d'Unix són el primer nivell de control, no l'únic: en entorns exigents es combinen amb ACL (lliçó 05-02) i amb control d'accés obligatori mitjançant AppArmor o SELinux (lliçó 06-06).

Els permisos que has dissenyat són necessaris i correctes. No són suficients per si sols quan hi ha dades personals pel mig, i presentar-los com a tals seria un error professional.

chmod -R 777 per «arreglar» un permís denegat. Emmascara la causa, exposa tot a qualsevol compte del sistema i és gairebé irreversible. Diagnostica amb id, ls -l i namei -l.

chmod -R 644 sobre un arbre. Deixa els directoris sense x i els trenca tots. Fes servir chmod -R u=rwX,g=rX,o=.

Oblidar la x als directoris del camí. El fitxer està bé i continua sense funcionar. namei -l /ruta/completa ho resol en un segon.

Creure que els permisos se sumen. S'aplica només la primera categoria que coincideix. Un propietari sense permisos no hi accedeix encara que el grup els tingui.

Protegir un fitxer i deixar la còpia .bak oberta. Fes servir cp -p i verifica-ho amb ls -l després.

Donar accés a un company amb o+r. L'hi estàs donant a tot el sistema. Grup, sempre.

usermod -G sense -a. Substitueix tots els grups secundaris. Et pot treure del grup sudo i deixar-te sense administració.

No entendre per què el grup nou «no funciona». Els grups s'apliquen en iniciar la sessió. Tanca la sessió i torna a entrar.

Consell: adopta umask 027 als servidors. Tot el que creïs neix ja tancat per a «altres». És mínim privilegi des de l'origen.

Consell: namei -l és l'eina més infravalorada d'aquesta lliçó. Memoritza-la.

Consell: stat -c '%a %A %U:%G %n' és el format de verificació. Et dona octal, simbòlic i propietat en una línia, perfecta per a informes.

Consell: abans de qualsevol chmod -R o chown -R, guarda l'estat actual. Amb getfacl -R directori > permisos.bak pots tornar enrere. És la versió de «còpia abans d'editar» aplicada als permisos.

Sense executar res:

1. Tradueix a octal: rwxr-x---, rw-rw-r--, r--------, rwsr-xr-x.
2. Tradueix a simbòlic: 750, 644, 2775, 1777.
3. Explica què pot fer exactament l'usuari luis (membre de tramontana, no d'adm) amb cadascun d'aquests, i per què:

4. Podria luis esborrar registre.log? Justifica la resposta.

L'aplicació no arrenca. Al registre del servei apareix:

El servei corre com a svc-tramontana. Comprova el següent i dona un diagnòstic raonat:

Identifica la causa exacta, proposa la correcció amb l'ordre concreta i explica per què no s'ha de resoldre amb chmod 644.

La Marta ha rebut una consulta del client i necessita un informe. Prepara per a srv-tramontana:

1. Una taula amb els permisos actuals de les cinc rutes de Tramontana, en octal i amb propietari.
2. La identificació de qualsevol ruta els permisos de la qual consideris incorrectes, amb la correcció proposada.
3. Un paràgraf, redactat per a algú no tècnic, explicant què protegeix aquest disseny i què no protegeix.

Solució 1

1. A octal:

A l'últim, la s a la posició de la x de l'usuari indica SUID, que aporta el 4 com a quart dígit. Els nou bits normals són 755.

2. A simbòlic:

A 2775, el 2 és SGID i es manifesta com a s a la x del grup. A 1777, l'1 és el sticky bit i apareix com a t a la posició de la x d'altres. Totes dues són minúscules perquè la x corresponent també hi és.

3. Què pot fer luis:

• /srv/dades (750, root:tramontana): luis no és root, així que no se li apliquen els permisos d'usuari. Sí que és membre de tramontana, així que se li aplica el grup: r-x. Pot llistar el directori (ls) i travessar-lo (cd, accedir al que hi ha a dins). No pot crear, esborrar ni reanomenar res a dins, perquè li falta w.

• config.txt (640, root:tramontana): se li aplica el grup, r--. El pot llegir amb cat. No el pot modificar. I hi pot arribar perquè té x al directori, condició necessària que es comprova primer.

• registre.log (640, root:adm): luis no és root ni membre d'adm, així que se li apliquen els permisos d'altres: ---. No el pot llegir. El fet que pugui llistar el directori i per tant veure que el fitxer existeix no li dona cap accés al seu contingut.

4. Pot luis esborrar registre.log?

No, però la raó no és la que sembla a primera vista.

Esborrar un fitxer no depèn dels permisos del fitxer: depèn de tenir w i x al directori que el conté. Si /srv/dades fos 770, luis sí que podria esborrar registre.log encara que no el pugui llegir, perquè estaria modificant la llista de noms del directori, no el fitxer.

En aquest cas concret no pot perquè /srv/dades és 750: el grup té r-x, sense w. És la manca de w al directori el que ho impedeix, no els permisos del registre.

Aquesta distinció és la que fa necessari el sticky bit en directoris com /tmp, on tothom té w.

Solució 2

Causa exacta. namei -l mostra la cadena completa i el bloqueig és a la primera línia rellevant:

El directori /etc/tramontana és 750, propietat de root:tramontana. El compte de servei:

svc-tramontana no pertany al grup tramontana. Només és al seu propi grup. En avaluar l'accés a /etc/tramontana:

• És el propietari root? No.
• Pertany al grup tramontana? No.
• Se li apliquen els permisos d'altres: ---.

Sense x a /etc/tramontana, no el pot travessar, així que ni tan sols arriba a avaluar els permisos d'app.conf. I encara que hi arribés, el fitxer també li donaria --- com a altres.

El detall important: el fitxer de configuració està perfectament configurat. El problema és la pertinença a grup del compte de servei. Sense namei -l és fàcil quedar-se mirant el 640 del fitxer i no veure el bloqueig real, que és un nivell més amunt.

Correcció:

La -a d'usermod -aG és imprescindible: sense ella, substituiria els grups secundaris en comptes d'afegir-hi.

I el systemctl restart és necessari perquè, com vas veure a l'apartat 7, els grups d'un procés es fixen en arrencar. Afegir el compte al grup no afecta un procés que ja s'està executant.

Per què no chmod 644:

chmod 644 /etc/tramontana/app.conf faria que el servei arrenqués, sí. I seria una fallada de seguretat greu.

El fitxer conté la contrasenya de la base de dades. Amb 644, qualsevol usuari del sistema la pot llegir: www-data, nobody, qualsevol compte de servei d'una altra aplicació, qualsevol usuari que es creï en el futur i qualsevol procés compromès que aconsegueixi executar-se amb un compte sense privilegis.

L'escenari concret: un atacant troba una vulnerabilitat menor en un altre servei del mateix servidor i aconsegueix executar ordres com a www-data. Amb 640 i el grup ben posat, no pot fer res amb les credencials de Tramontana. Amb 644, llegeix la contrasenya de la base de dades, s'hi connecta directament i s'emporta totes les dades d'hostes. Un incident contingut es converteix en una filtració.

A més, 644 no arregla la causa. El compte de servei continua sense ser al grup al qual pertanyen tots els altres recursos de l'aplicació. El mateix error tornarà a aparèixer amb els registres, amb el directori de còpies i amb cada recurs nou, i s'anirà apedaçant cada vegada obrint permisos, fins a acabar amb un desplegament completament exposat.

El principi general: quan alguna cosa dona «permission denied», la pregunta correcta no és «com obro això», sinó «qui hauria de tenir-hi accés i com l'hi dono només a ells». La resposta gairebé sempre és la pertinença a un grup, no un chmod més permissiu.

Solució 3

1. Estat actual:

2. Correccions proposades:

Sense SGID, una còpia creada per un altre membre de l'equip naixeria amb el seu grup personal i la resta no la podria gestionar. Amb SGID, tot el que es crea a dins hereta tramontana. És el requisit perquè un directori compartit funcioni realment en equip.

Amb 775, qualsevol usuari del sistema podia llegir els scripts d'administració. Això no és trivial: els scripts revelen rutes internes, noms de serveis, procediments de còpia i de vegades —per descuit— credencials. És informació de reconeixement gratis per a un atacant.

Una comprovació addicional que val la pena fer sempre:

Totes dues amb 640. Correcte, gràcies al cp -p.

3. Informe per a la Marta:

Disseny de permisos d'accés — Tramontana Reserves

El servidor controla qui pot veure i modificar cada fitxer mitjançant un sistema de permisos que assigna a cada fitxer un propietari, un grup de treball i uns drets concrets per a cadascun. Hem revisat i ajustat els cinc elements del desplegament.

Què protegeix el disseny actual. El codi de l'aplicació pertany a l'administrador i l'aplicació el pot executar però no modificar: si algú aconseguís explotar una fallada del programa, no podria alterar el mateix programa per instal·lar-s'hi de manera permanent. El fitxer de configuració, que conté la contrasenya de la base de dades, només és llegible per l'administrador i pels comptes de l'equip de Tramontana; cap altre compte del servidor no el pot veure, ni tan sols els d'altres serveis que hi pugui haver instal·lats. Els registres d'activitat, que inclouen dades d'ús dels clients, estan igualment restringits. Les còpies de seguretat són accessibles només per a l'equip, i hi hem afegit un ajust perquè qualsevol còpia que generi qualsevol membre de l'equip quedi automàticament accessible a la resta, evitant que una còpia acabi sent inutilitzable per un problema de permisos. Finalment, hem tancat l'accés als scripts d'administració, que fins ara podia llegir qualsevol compte del servidor i que descriuen el funcionament intern del sistema.

Què no protegeix. Aquest mecanisme controla l'accés des de dins del servidor i entre comptes diferents. No protegeix davant de tres coses: qui tingui accés d'administrador ho pot llegir tot, perquè aquesta és la naturalesa del rol; les dades estan emmagatzemades sense xifrar, de manera que qui obtingués accés físic al disc o a una còpia de seguretat les podria llegir sense necessitat de credencials; i no impedeix que algú amb accés legítim copiï informació fora del servidor.

Recomanació. Atès que el sistema emmagatzema noms d'hostes, dates d'estada i imports —dades personals subjectes al RGPD—, aquest disseny hauria de ser revisat i validat pel responsable de protecció de dades abans de considerar-lo definitiu. És probable que la normativa exigeixi, a més del control d'accés que ja tenim, el xifratge de les dades emmagatzemades i un registre auditable dels accessos. Proposo tractar-ho a la propera reunió i planificar aquestes dues mesures com a fase següent.

Aquest informe compleix el que s'espera d'un professional: descriu el que s'ha fet en llenguatge comprensible, és honest sobre els límits de la solució, i eleva a qui correspon una decisió que no és tècnica sinó de compliment normatiu.

Tanques el Mòdul 2 amb la peça que faltava: la que converteix un servidor que funciona en un servidor que a més és segur.

• El model d'Unix assigna a cada fitxer un propietari i un grup, i divideix la resta del món en tres categories. Els permisos no se sumen: se selecciona la primera categoria que coincideix.
• Saps llegir -rw-r----- caràcter a caràcter, i reconeixes els set tipus de fitxer per la seva primera lletra.
• Entens que r, w i x signifiquen coses diferents en fitxers i en directoris: que x és travessar, que r sense x és gairebé inútil, i que w en un directori permet esborrar fitxers que no són teus, perquè esborrar és una operació sobre la llista de noms, no sobre el fitxer.
• Tradueixes entre octal i simbòlic en tots dos sentits, i coneixes els valors que apareixen de debò: 644, 640, 600, 755, 750, 700, 711.
• Fas servir chmod en les dues notacions, i saps que el recursiu correcte és u=rwX,g=rX,o= amb X majúscula, mai -R 644 ni -R 777.
• Saps per què chmod -R 777 no és una solució i quin és el diagnòstic correcte: id, ls -l i sobretot namei -l.
• Manejes chown i chgrp, saps que chown exigeix root i per què, i coneixes --reference i -h.
• Tens clar que el treball en equip es resol amb un grup compartit i no amb permisos per a «altres», que usermod -aG necessita la -a, i que els grups s'apliquen en iniciar la sessió.
• Calcules la umask i el seu efecte sobre les bases 666 i 777, i saps que 027 és la recomanable en un servidor amb dades sensibles.
• Reconeixes SUID, SGID i sticky en un ls -l, saps què fa cadascun en una frase, i saps que el seu estudi a fons és la lliçó 05-02.
• I has dissenyat i justificat els permisos complets del desplegament de Tramontana Reserves, inclosa la part més professional de totes: dir amb claredat què protegeix el disseny i què no, i elevar a qui correspon el que excedeix el teu àmbit de decisió.

Fes balanç del mòdul sencer. Vas començar amb un indicador parpellejant i sense saber com escriure una ordre amb soltesa. Ara manegues la línia d'ordres amb dreceres i historial, resols dubtes amb la documentació del sistema sense dependre d'un cercador, recorres i caracteritzes un servidor desconegut amb cinc ordres, crees, copies, mous, empaquetes i verifiques fitxers amb procediments reproduïbles, llegeixes i edites contingut amb less, nano i el vim just per no quedar-te tancat, entens què és un inode i has dissenyat un patró de desplegament amb enllaços, i saps decidir qui accedeix a què i per què. Això ja no és «saber ordres»: és tenir criteri.

Al Mòdul 3: Habilitats Avançades a la Línia d'Ordres tot això es multiplica. Aprendràs a personalitzar el teu entorn amb variables, àlies i historial persistent, a descriure conjunts de fitxers amb comodins i patrons amb expressions regulars, a buscar qualsevol cosa a qualsevol lloc amb find, locate i grep, a encadenar programes amb canonades i a redirigir-ne l'entrada i la sortida —aquella mecànica que has fet servir de rebot i que per fi entendràs del tot—, a processar text amb cut, sort, uniq, sed i awk fins a convertir acces.log i reserves.csv en els informes que la Marta demana, a controlar els processos del sistema i a programar tasques amb cron perquè s'executin soles de matinada. És el mòdul on deixes d'executar ordres una a una i comences a compondre-les, que és exactament el que anunciava la filosofia Unix del primer mòdul. Actualitza la instantània de la teva VM i ens hi veiem.