sudo e permessi minimi

Modulo 3: Utenti, permessi e sudo · Tempo di lettura: 11 minuti

Obiettivo della lezione: Dopo questa lezione Lei sarà in grado di lavorare come utente normale con sudo, aggiungere un amministratore in modo sicuro, modificare le impostazioni di sudo senza chiudersi fuori e spiegare perché i permessi minimi proteggono il Suo server.

Concetti chiave: sudo, gruppo sudo, gruppo wheel, /etc/sudoers, /etc/sudoers.d, visudo, NOPASSWD, sudo -l, bloccare root, log di sudo, permessi minimi (least privilege), utente di servizio

Perché non lavorare semplicemente come root?

Dopo l'installazione spesso si accede come root. È comodo: tutto è permesso. Ma il problema è proprio questo:

• Basta un errore di battitura. rm -rf / home/anna/oud (noti lo spazio dopo la prima barra) cancella come root l'intero server. Come utente normale riceve un messaggio di errore.
• Tutto viene eseguito come root. Uno script copiato da internet, un programma che sta provando: tutto ottiene permessi completi.
• Nessuna traccia. Se tre persone lavorano come root, a posteriori nessuno sa chi ha fatto cosa.
• Root è il nome che ogni attaccante prova. È meglio disattivare del tutto l'accesso come root (lezione 2.2), ma è possibile solo quando dispone di un'altra strada per ottenere i permessi di amministratore.

Quest'altra strada è sudo: accede con il Suo utente e mette sudo solo davanti a un comando che richiede permessi di amministratore.

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
...

(Dalla versione 25.10 Ubuntu usa per impostazione predefinita sudo-rs, una nuova implementazione di sudo. Per tutto ciò che vediamo in questa lezione funziona allo stesso modo.)

sudo chiede la Sua password, non quella di root. Poi, per impostazione predefinita, la ricorda per un quarto d'ora, così non deve reinserirla a ogni comando. Ogni comando eseguito con sudo finisce nel log.

Creare un amministratore

Su Debian e Ubuntu chiunque faccia parte del gruppo sudo può fare tutto tramite sudo. Questo è scritto in /etc/sudoers:

%sudo   ALL=(ALL:ALL) ALL

Si legge così: i membri del gruppo sudo (%) possono eseguire su tutte le macchine (ALL), come qualsiasi utente e gruppo ((ALL:ALL)), qualsiasi comando (ALL).

Aggiungere un amministratore richiede quindi due passaggi, come root:

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

Poi inserisca la chiave pubblica di Anna in /home/anna/.ssh/authorized_keys con il proprietario e i permessi corretti:

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

Non dimentichi il chown: se è stato copiato da root, il file appartiene a root, e Anna non può accedere con la sua chiave.

Ora, tenendo aperta la sessione di root, provi in una seconda finestra:

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

Solo quando questo funziona, imposti nella configurazione SSH PermitRootLogin no (lezione 2.2). Da quel momento accederà sempre come Anna.

Una cosa da ricordare: ora Anna ha bisogno di una password per sudo. La conservi nel Suo password manager. L'accesso avviene con la chiave, sudo con la password: due cose diverse che un intruso deve possedere entrambe.

Modificare le impostazioni di sudo: sempre con visudo

Un errore in /etc/sudoers può far sì che sudo smetta del tutto di funzionare. Se anche root non può accedere, Lei resta bloccato. Per questo le impostazioni di sudo non si modificano mai con un editor normale, ma con visudo. Apre una copia temporanea e ne controlla il contenuto prima di salvare:

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

Come per SSH, è preferibile usare un file proprio in /etc/sudoers.d/ invece del file principale. Faccia attenzione a due regole di questa cartella:

• I file il cui nome contiene un punto o termina con ~ vengono ignorati. backup.conf quindi non funziona, backup sì. Serve a ignorare le copie create dagli editor, ma sorprende molte persone.
• Il file deve appartenere a root e non essere scrivibile da altri (440 è il valore consueto; visudo se ne occupa).

Se vuole controllare un file esistente senza modificarlo: visudo -c controlla tutto.

NOPASSWD: comodo, ma sappia cosa sta facendo

Con NOPASSWD sudo non chiede più la password:

anna ALL=(ALL:ALL) NOPASSWD: ALL

Alcune immagini VPS lo impostano per l'utente predefinito, così dopo l'accesso con una chiave si è subito amministratori. Con sudo -l verifichi cosa vale nel Suo caso. La conseguenza: chi possiede la chiave di Anna è subito root. Non c'è più una seconda serratura. Per un server personale può fare questa scelta, ma la faccia consapevolmente.

Molto meglio usare NOPASSWD solo per un comando specifico, ad esempio per uno script di backup che deve poter essere eseguito automaticamente:

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

L'utente backup può allora eseguire come root esattamente quell'unico script, senza password, e nient'altro. Due trappole:

• Usi sempre il percorso completo. Con il solo maak-backup qualcuno può mettere un proprio programma con quel nome all'inizio del suo percorso.
• Lo script stesso non deve essere scrivibile da quell'utente. Altrimenti può modificarlo ed eseguire comandi arbitrari come root. Lo stesso vale per i comandi che possono aprire da soli una shell, come un editor (vim, nano) o less: chi può avviarli tramite sudo può aprire una shell di root dall'interno del programma. Non conceda mai comandi del genere da soli tramite sudo.

Che cosa viene registrato

Ogni volta che qualcuno usa sudo, viene scritta una riga nel journal (e, sui sistemi con rsyslog, anche in /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 chi, dove, come quale utente e quale comando. È uno dei motivi per non lavorare in più persone come root. I tentativi di sudo falliti ("incorrect password attempts", cioè password errate) da un account che non è il Suo sono un segnale d'allarme.

Permessi minimi su larga scala

sudo è un'applicazione di un principio generale: i permessi minimi (least privilege). Ogni utente e ogni servizio riceve esattamente i permessi necessari, e non di più. Su un server questo significa tra l'altro:

• lavora come utente normale e usa sudo solo quando serve;
• ogni servizio gira con un proprio utente senza shell (lezione 3.1), non come root;
• un'applicazione web riceve un utente di database che può usare solo il proprio database, non l'amministratore del server di database;
• uno script di backup può eseguire solo l'unico comando di cui ha bisogno (NOPASSWD con percorso completo);
• un collega che aggiorna solo il sito web riceve il permesso di scrittura su /var/www/example.com tramite un gruppo, non sudo.

L'idea: se qualcosa va storto (una falla in un plugin, una chiave rubata), il danno resta limitato a quell'unico utente o servizio. Nei principi CIS e nella lezione sull'hardening (10.1) questo concetto ritorna di continuo.

Su AlmaLinux e Rocky Linux

Lì il gruppo degli amministratori si chiama wheel invece di sudo: usermod -aG wheel anna. La riga in /etc/sudoers è %wheel ALL=(ALL) ALL. visudo e /etc/sudoers.d funzionano allo stesso modo. Lì i messaggi di sudo si trovano anche in /var/log/secure.

Riepilogo

• Lavori come utente normale e usi sudo per l'amministrazione; sudo chiede la Sua password e registra ogni comando.
• Creare un amministratore: adduser anna, adduser anna sudo (wheel sui sistemi derivati da RHEL), chiave con proprietario e permessi corretti, test in una seconda finestra, solo dopo disattivare l'accesso come root.
• Modifichi le regole di sudo solo con visudo, preferibilmente in un file proprio in /etc/sudoers.d/ senza punto nel nome.
• NOPASSWD per tutto elimina una serratura; è meglio usarlo solo per un comando con percorso completo che l'utente non può modificare.
• Permessi minimi: ogni utente e servizio riceve esattamente ciò che serve, così un errore o una falla restano piccoli.

Quiz

Esercizio

Esercizio O3.2: Un amministratore con sudo. Crei sul Suo server un amministratore normale (ad esempio anna), sistemi la Sua chiave, provi l'accesso e sudo -l in una seconda finestra, e poi disattivi l'accesso come root tramite SSH (PermitRootLogin no). Spunti i passaggi, incolli l'output di id (solo nome e gruppi) e risponda alle domande: quale riga dà i permessi al Suo amministratore, compare NOPASSWD da qualche parte, e come entra se dimentica la password?

Per approfondire

I passaggi descritti in questi articoli valgono per i VPS di WebOké; con altri fornitori il funzionamento è simile.

• Proteggere il suo VPS: i primi cinque minuti
• Nessun accesso alla sua VPS: cosa fare?
• Guida DirectAdmin 12.2: Utenti, permessi e password dei database
• Ubuntu Server: User management: https://ubuntu.com/server/docs/how-to/security/user-management/
• Manuale Debian di sudoers: https://manpages.debian.org/trixie/sudo/sudoers.5.en.html