Cum creați un utilizator cu acces limitat în Linux

Cum creați un utilizator cu acces limitat în Linux este întrebarea corectă de pus înainte de a da cuiva parola de root „doar ca să încarce niște fișiere”. Un cont cu drepturi minime lasă colaboratorul, scriptul sau serviciul să facă exact ce trebuie și nimic în plus, iar când parola lui ajunge unde nu trebuie, paguba se oprește la dosarul lui.

Ghidul acoperă cele trei situații pe care le întâlnim cel mai des: un cont pentru un colaborator care încarcă fișiere pe site, un cont pentru un serviciu sau un script care rulează singur, și un cont de administrare cu sudo doar pentru câteva comenzi. Comenzile sunt valabile pe Ubuntu și AlmaLinux; unde diferă, spunem.

Cum creați un utilizator cu acces limitat în Linux

Crearea contului

Pe Ubuntu, adduser este comanda prietenoasă: creează dosarul personal, cere parola și completează câmpurile de identificare. useradd, disponibilă peste tot, face același lucru cu opțiuni explicite:

sudo adduser maria                          # Ubuntu, interactiv
sudo useradd -m -s /bin/bash maria && sudo passwd maria   # oriunde
id maria                                    # uid, gid și grupurile

Un utilizator nou nu are, implicit, niciun drept special: nu poate rula sudo, nu poate citi dosarele altor utilizatori (dacă acestea au 750 sau 700) și nu poate scrie în afara dosarului propriu și a dosarelor cu scriere pentru toți, precum /tmp. Verificați apartenența la grupuri: pe Ubuntu, grupul sudo dă drepturi de administrator, pe AlmaLinux grupul wheel.

groups maria
sudo gpasswd -d maria sudo        # Ubuntu, dacă a ajuns acolo din greșeală
sudo gpasswd -d maria wheel       # AlmaLinux

Dosarul personal cu acces restrâns

Pe Ubuntu 21.04 și mai nou, dosarele personale se creează cu 750, deci ceilalți utilizatori nu le pot citi. Pe AlmaLinux sunt 700. Pe sisteme mai vechi, verificați și corectați:

ls -ld /home/maria
sudo chmod 750 /home/maria

Regulile de permisiuni și cazul dosarelor partajate între mai mulți utilizatori, cu setgid, sunt explicate în ghidul despre chmod și chown.

Cazul 1: colaboratorul care încarcă fișiere

Un designer sau o firmă externă trebuie să modifice fișierele unui site, nimic altceva. Soluția potrivită este SFTP izolat (chroot): utilizatorul se conectează cu un client SFTP, vede doar dosarul site-ului și nu are shell.

sudo useradd -m -s /usr/sbin/nologin -G sftp-site design
sudo passwd design
sudo tee /etc/ssh/sshd_config.d/60-sftp.conf <<'EOT'
Match Group sftp-site
    ChrootDirectory /var/www/exemplu.ro
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no
EOT
sudo sshd -t && sudo systemctl restart sshd

Grupul sftp-site trebuie creat înainte (groupadd sftp-site). Dosarul de chroot are o condiție strictă: trebuie să aparțină lui root și să nu fie scriibil de altcineva; utilizatorul primește scriere doar pe un subdosar, de exemplu public, care aparține lui. Dacă condiția nu e respectată, conexiunea se închide imediat, iar jurnalul SSH spune „bad ownership or modes for chroot directory”.

sudo chown root:root /var/www/exemplu.ro
sudo chmod 755 /var/www/exemplu.ro
sudo chown -R design:www-data /var/www/exemplu.ro/public

Shell-ul /usr/sbin/nologin (pe AlmaLinux /sbin/nologin) refuză autentificarea interactivă, dar permite SFTP prin ForceCommand. Nu folosiți /bin/false pentru asta: pe unele sisteme blochează și SFTP.

Cazul 2: utilizatorul pentru un serviciu sau un script

O aplicație web, un proces de coadă sau un script de copii de siguranță trebuie să ruleze sub un cont propriu, fără parolă și fără posibilitate de autentificare. Se numesc utilizatori de sistem și au uid sub 1000:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin coada
sudo mkdir -p /var/lib/coada && sudo chown coada:coada /var/lib/coada

Serviciul se pornește sub acest utilizator din unitatea systemd, cu directivele User= și Group=, iar dosarele în care scrie sunt singurele pe care le deține. Dacă serviciul are nevoie de un port sub 1024, nu îi dați root: folosiți AmbientCapabilities=CAP_NET_BIND_SERVICE în unitate. Pentru PHP-FPM, fiecare site primește un bazin cu propriul utilizator de sistem, așa cum am arătat în ghidul despre instalarea LAMP pe Ubuntu.

Scripturile programate rulează din crontab-ul utilizatorului respectiv (sudo crontab -u coada -e), nu din al lui root. Un script de copii de siguranță care are nevoie să citească fișierele altor utilizatori primește acces prin grup sau prin ACL, nu prin sudo; exemplul complet este în articolul despre copiile de siguranță cu cron și rsync.

Cazul 3: administrator cu sudo pentru câteva comenzi

Un coleg trebuie să repornească serverul web și să citească jurnalele, dar nu să instaleze pachete sau să editeze configurații. sudoers permite exact asta. Regulile se scriu într-un fișier separat în /etc/sudoers.d/, întotdeauna prin visudo, care verifică sintaxa înainte de salvare:

sudo visudo -f /etc/sudoers.d/ops-web

Cmnd_Alias WEB = /usr/bin/systemctl restart apache2, /usr/bin/systemctl reload apache2, /usr/bin/systemctl status apache2
Cmnd_Alias JURNALE = /usr/bin/journalctl -u apache2*, /usr/bin/tail -n * /var/log/apache2/*
andrei ALL=(root) WEB, JURNALE

Câteva reguli de scriere: căi absolute, fără caractere joker la comanda în sine (systemctl * ar permite orice), fără comenzi care deschid un editor sau un shell (vim, less, more, bash pot lansa alt program din interior). Verificați ce poate rula utilizatorul cu sudo -l -U andrei. Fișierul din sudoers.d trebuie să aibă 440 și să nu conțină punct sau tildă în nume, altfel este ignorat fără avertisment.

Pentru comenzi fără parolă, de exemplu din scripturi, adăugați NOPASSWD: înaintea listei de comenzi, dar doar pentru comenzi precise, nu pentru ALL. Un sudo fără parolă pe ALL înseamnă că oricine intră pe cont are root.

Accesul SSH: chei, fără parole

Orice cont care se conectează de la distanță ar trebui să folosească chei, nu parole. Utilizatorul își generează cheia local și vă trimite partea publică, pe care o puneți în authorized_keys al contului:

sudo mkdir -p /home/maria/.ssh
sudo tee -a /home/maria/.ssh/authorized_keys < cheia-mariei.pub
sudo chown -R maria:maria /home/maria/.ssh
sudo chmod 700 /home/maria/.ssh && sudo chmod 600 /home/maria/.ssh/authorized_keys

În configurația SSH, directiva AllowUsers sau AllowGroups limitează cine se poate conecta deloc; un utilizator de sistem nu apare acolo și nu poate intra chiar dacă cineva îi pune o parolă. Restul măsurilor, de la portul SSH la blocarea încercărilor repetate, sunt în ghidul despre atacurile brute force pe SSH și în cel despre fail2ban.

Limitarea resurselor

Un cont limitat poate totuși consuma tot procesorul sau tot discul. Cotele de disc (pachetul quota) limitează spațiul pe utilizator, iar /etc/security/limits.conf limitează numărul de procese și fișiere deschise:

design   hard   nproc    100
design   hard   nofile   4096

Pe servere cu mai mulți utilizatori, aceste limite opresc un script scăpat de sub control să blocheze restul serviciilor; consumul se urmărește cu htop și atop.

Verificarea contului

1. Autentificați-vă ca utilizatorul nou (sudo -iu maria) și încercați să citiți /etc/shadow, /root și dosarul altui utilizator: toate trebuie să dea Permission denied.
2. Rulați sudo -l: pentru un cont fără drepturi, răspunsul este că utilizatorul nu poate rula sudo pe acest sistem.
3. Pentru SFTP izolat, conectați-vă cu un client și încercați să urcați deasupra dosarului de chroot; nu trebuie să fie posibil.
4. Pentru utilizatorii de sistem, confirmați că su: coada este refuzat și că procesul serviciului rulează sub uid-ul corect (ps -o user,cmd -C nume-proces).
5. Verificați jurnalul de autentificări după prima conectare reală: journalctl -u ssh (Ubuntu) sau journalctl -u sshd (AlmaLinux), așa cum arătăm în ghidul journalctl.

Ce nu ține loc de cont limitat

Trei practici pe care le vedem des și care par să rezolve problema, dar nu o rezolvă. Prima: un singur cont partajat de toată echipa, cu parola trimisă pe chat. Nu știți cine a făcut ce, iar plecarea unei persoane obligă la schimbarea parolei pentru toți. A doua: contul de root cu o parolă „bună” dat colaboratorului externe pentru o zi. O zi ajunge pentru a instala o cheie SSH sau un cron care rămâne după. A treia: FTP simplu, cu parolă în clar pe rețea, pentru că „e doar pentru fișiere”; parola se prinde pe orice rețea publică, iar contul FTP are de obicei acces la tot dosarul personal.

Un cont limitat rezolvă toate trei cu aceleași comenzi de mai sus și cu zece minute de lucru. Dacă rulați cPanel, echivalentul este un cont FTP restrâns la un dosar sau un utilizator suplimentar cu drepturi alese, ambele din panou; principiile sunt identice.

Când contul limitat are nevoie de mai mult

Se întâmplă ca sarcina să crească: colaboratorul trebuie să și repornească un serviciu, scriptul trebuie să și citească un dosar al altui utilizator. Rezistați tentației de a-i da sudo pe tot. Adăugați exact comanda în sudoers.d, exact dosarul prin ACL (setfacl -m u:design:rx /var/log/apache2) sau exact grupul de care are nevoie. Fiecare drept adăugat se notează, cu data și motivul, într-un fișier de evidență a serverului; peste un an, când cineva întreabă de ce utilizatorul design poate citi jurnalele Apache, răspunsul este acolo.

Revizuiți conturile o dată pe trimestru: lista din /etc/passwd cu uid peste 1000, ultima autentificare a fiecăruia (comanda lastlog) și drepturile din sudoers. Conturile fără autentificare de peste 90 de zile se blochează.

Dezactivarea și ștergerea

Când colaborarea se încheie, întâi blocați contul, apoi ștergeți-l după ce ați verificat că nu rulează nimic sub el:

sudo usermod -L -e 1 maria           # blochează parola și expiră contul
sudo pkill -u maria                  # oprește procesele rămase
sudo deluser --remove-home maria     # Ubuntu; pe AlmaLinux: userdel -r maria

Cheile din authorized_keys dispar odată cu dosarul personal, dar verificați și /etc/sudoers.d/, crontab-urile și eventualele fișiere deținute de utilizator în afara dosarului lui (find / -user maria). Pe un server cu cPanel, conturile de acest tip se creează din panou, cu aceleași principii, iar ghidul de securitate al contului cPanel descrie ce drepturi primește fiecare tip de cont. Contextul general de întărire a sistemului, în care conturile limitate sunt doar un capitol, este în ghidul de securitate pentru AlmaLinux 9.

Surse

• Documentația Ubuntu Server, securitate: administrarea utilizatorilor, sudo și configurarea OpenSSH.
• Manualul de securizare Debian: principiul drepturilor minime, limitele de resurse și chroot.