sudo și permisiunile minime

Modulul 3: Utilizatori, permisiuni și sudo · Timp de citire: 11 minute

Obiectivul lecției: După această lecție veți putea lucra ca utilizator obișnuit cu sudo, veți putea adăuga în siguranță un administrator, veți putea modifica setările sudo fără să vă blocați singur accesul și veți putea explica de ce permisiunile minime vă protejează serverul.

Noțiuni cheie: sudo, grupul sudo, grupul wheel, /etc/sudoers, /etc/sudoers.d, visudo, NOPASSWD, sudo -l, blocarea contului root, jurnalul sudo, permisiuni minime (least privilege), utilizator de serviciu

De ce să nu lucrați pur și simplu ca root?

După instalare vă autentificați adesea ca root. Este comod: totul este permis. Dar tocmai aceasta este problema:

• O singură greșeală de tastare este suficientă. rm -rf / home/anna/oud (atenție la spațiul de după prima bară oblică) vă șterge, ca root, întregul server. Ca utilizator obișnuit primiți un mesaj de eroare.
• Totul rulează ca root. Un script copiat de pe internet, un program pe care îl testați: totul primește permisiuni depline.
• Nicio urmă. Dacă trei persoane lucrează ca root, nimeni nu mai știe ulterior cine ce a făcut.
• Root este numele pe care îl încearcă orice atacator. Este mai bine să dezactivați complet autentificarea ca root (lecția 2.2), dar acest lucru este posibil doar dacă aveți o altă cale către drepturile de administrare.

Această altă cale este sudo: vă autentificați cu propriul cont și adăugați sudo doar înaintea unei comenzi care necesită drepturi de administrare.

anna@web1:~$ apt update
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
anna@web1:~$ sudo apt update
[sudo] password for anna:
Hit:1 http://deb.debian.org/debian trixie InRelease
...

(Începând cu versiunea 25.10, Ubuntu folosește implicit sudo-rs, o nouă implementare a sudo. Pentru tot ce este descris în această lecție, aceasta funcționează la fel.)

sudo vă cere parola dumneavoastră, nu pe cea a contului root. Apoi o reține implicit timp de un sfert de oră, astfel încât să nu fie nevoie să o introduceți din nou la fiecare comandă. Fiecare comandă pe care o executați cu sudo ajunge în jurnal.

Crearea unui administrator

Pe Debian și Ubuntu, oricine face parte din grupul sudo poate face orice prin sudo. Acest lucru este definit în /etc/sudoers:

%sudo   ALL=(ALL:ALL) ALL

Citiți astfel: membrii grupului sudo (%) pot executa pe toate mașinile (ALL), ca orice utilizator și grup ((ALL:ALL)), orice comandă (ALL).

Adăugarea unui administrator se face așadar în doi pași, ca root:

root@web1:~# adduser anna
root@web1:~# adduser anna sudo

Puneți apoi cheia publică a Annei în /home/anna/.ssh/authorized_keys, cu proprietarul și permisiunile corecte:

root@web1:~# mkdir -p /home/anna/.ssh
root@web1:~# cp /root/.ssh/authorized_keys /home/anna/.ssh/
root@web1:~# chown -R anna:anna /home/anna/.ssh
root@web1:~# chmod 700 /home/anna/.ssh
root@web1:~# chmod 600 /home/anna/.ssh/authorized_keys

Nu uitați de chown: dacă fișierul este copiat de root, el aparține lui root, iar atunci Anna nu se poate autentifica cu cheia ei.

Testați acum, cu sesiunea root încă deschisă, într-o a doua fereastră:

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$ sudo -l
[sudo] password for anna:
User anna may run the following commands on web1:
    (ALL : ALL) ALL
anna@web1:~$ sudo whoami
root

Abia după ce acest lucru funcționează, setați în configurația SSH PermitRootLogin no (lecția 2.2). De acum înainte vă autentificați întotdeauna ca Anna.

Un lucru de reținut: Anna are acum nevoie de o parolă pentru sudo. Păstrați-o în managerul de parole. Autentificarea se face cu cheia, sudo cu parola: două lucruri diferite, pe care un intrus trebuie să le dețină pe amândouă.

Modificarea setărilor sudo: întotdeauna cu visudo

O greșeală în /etc/sudoers poate face ca sudo să nu mai funcționeze deloc. Dacă nici root nu se poate autentifica, ați rămas blocat. De aceea nu editați niciodată setările sudo cu un editor obișnuit, ci cu visudo. Acesta deschide o copie temporară și verifică conținutul înainte de a salva:

root@web1:~# visudo -f /etc/sudoers.d/backup

La fel ca la SSH, folosiți mai bine un fișier propriu în /etc/sudoers.d/ decât fișierul principal. Țineți cont de două reguli ale acestui director:

• Fișierele al căror nume conține un punct sau se termină cu ~ sunt ignorate. backup.conf nu funcționează, așadar, dar backup funcționează. Scopul este ignorarea copiilor create de editoare, dar mulți oameni sunt surprinși de acest lucru.
• Fișierul trebuie să aparțină lui root și să nu poată fi scris de alții (440 este valoarea uzuală; visudo se ocupă de acest lucru).

Dacă doriți să verificați un fișier existent fără să îl editați: visudo -c verifică totul.

NOPASSWD: comod, dar trebuie să știți ce faceți

Cu NOPASSWD, sudo nu mai cere parolă:

anna ALL=(ALL:ALL) NOPASSWD: ALL

Unele imagini VPS setează acest lucru pentru utilizatorul implicit, astfel încât, după autentificarea cu o cheie, sunteți imediat administrator. Verificați cu sudo -l ce se aplică în cazul dumneavoastră. Consecința: cine are cheia Annei este imediat root. Nu mai există un al doilea lacăt. Pentru un server personal puteți alege această variantă, dar faceți-o în mod conștient.

Mult mai bine este să folosiți NOPASSWD doar pentru o singură comandă anume, de exemplu pentru un script de backup care trebuie să poată rula automat:

backup ALL=(root) NOPASSWD: /usr/local/bin/maak-backup

Utilizatorul backup poate rula atunci exact acel script ca root, fără parolă, și nimic altceva. Două capcane:

• Folosiți întotdeauna calea completă. Doar cu maak-backup, cineva poate pune un program propriu cu acel nume la începutul căii sale.
• Scriptul în sine nu trebuie să poată fi modificat de acel utilizator. Altfel, îl poate modifica și apoi poate rula comenzi arbitrare ca root. Același lucru este valabil pentru comenzile care pot deschide ele însele un shell, cum ar fi un editor (vim, nano) sau less: cine le poate porni prin sudo poate deschide din program un shell de root. Nu acordați niciodată astfel de comenzi separat prin sudo.

Ce se înregistrează în jurnal

De fiecare dată când cineva folosește sudo, apare o linie în journal (iar pe sistemele cu rsyslog și în /var/log/auth.log):

anna@web1:~$ sudo journalctl _COMM=sudo --since today
Nov 09 10:31:02 web1 sudo[2214]:     anna : TTY=pts/0 ; PWD=/home/anna ; USER=root ; COMMAND=/usr/bin/apt update

Vedeți cine, de unde, ca cine și ce comandă. Acesta este unul dintre motivele pentru care nu se recomandă ca mai multe persoane să lucreze ca root. Încercările eșuate de sudo („incorrect password attempts”, adică încercări cu parolă greșită) de la un cont care nu este al dumneavoastră sunt un semnal de alarmă.

Permisiunile minime la scară largă

sudo este o aplicare a unui principiu general: permisiunile minime (least privilege). Fiecare utilizator și fiecare serviciu primește exact permisiunile necesare, și nu mai mult. Pe un server, aceasta înseamnă, printre altele:

• lucrați ca utilizator obișnuit și folosiți sudo doar atunci când este necesar;
• fiecare serviciu rulează sub propriul utilizator, fără shell (lecția 3.1), nu ca root;
• o aplicație web primește un utilizator de bază de date care poate folosi doar propria bază de date, nu administratorul serverului de baze de date;
• un script de backup are voie să ruleze doar acea comandă de care are nevoie (NOPASSWD cu cale completă);
• un coleg care doar actualizează site-ul primește drept de scriere pe /var/www/example.com printr-un grup, nu sudo.

Ideea: dacă ceva merge prost (o vulnerabilitate într-un plugin, o cheie furată), paguba rămâne limitată la acel utilizator sau serviciu. Acest principiu revine mereu în principiile CIS și în lecția despre hardening (10.1).

Pe AlmaLinux și Rocky Linux

Acolo grupul de administratori se numește wheel în loc de sudo: usermod -aG wheel anna. Regula din /etc/sudoers este %wheel ALL=(ALL) ALL. visudo și /etc/sudoers.d funcționează la fel. Mesajele sudo apar acolo și în /var/log/secure.

Rezumat

• Lucrați ca utilizator obișnuit și folosiți sudo pentru administrare; sudo vă cere propria parolă și înregistrează fiecare comandă.
• Crearea unui administrator: adduser anna, adduser anna sudo (wheel pe sistemele de tip RHEL), cheia cu proprietarul și permisiunile corecte, testare într-o a doua fereastră, abia apoi dezactivarea autentificării root.
• Editați regulile sudo doar cu visudo, de preferință într-un fișier propriu în /etc/sudoers.d/, fără punct în nume.
• NOPASSWD pentru orice înlătură un lacăt; folosiți-l mai bine doar pentru o singură comandă, cu cale completă, pe care utilizatorul nu o poate modifica.
• Permisiuni minime: fiecare utilizator și serviciu primește exact ce îi trebuie, astfel încât o greșeală sau o vulnerabilitate rămâne de mică amploare.

Test (quiz)

Exercițiu

Exercițiul O3.2: Un administrator cu sudo. Creați pe serverul dumneavoastră un administrator obișnuit (de exemplu anna), configurați corect cheia, testați autentificarea și sudo -l într-o a doua fereastră, apoi dezactivați autentificarea root prin SSH (PermitRootLogin no). Bifați pașii, lipiți rezultatul comenzii id (doar numele și grupurile) și răspundeți la întrebări: ce regulă îi oferă drepturi administratorului dumneavoastră, apare undeva NOPASSWD și cum intrați pe server dacă vă uitați parola?

Lecturi suplimentare

Pașii din aceste articole se aplică VPS-urilor WebOké; la alți furnizori procedura este similară.

• Securizarea VPS-ului dumneavoastră: primele cinci minute
• Nu mai aveți acces la VPS-ul dumneavoastră: ce puteți face?
• Manual DirectAdmin 12.2: Utilizatori de baze de date, drepturi și parole
• Ubuntu Server: User management: https://ubuntu.com/server/docs/how-to/security/user-management/
• Manualul Debian pentru sudoers: https://manpages.debian.org/trixie/sudo/sudoers.5.en.html
• VPS: de la prima autentificare la un server securizat 3.1: Un utilizator propriu cu sudo