Configurare SUDO per gestire le attività degli amministratori: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
mNessun oggetto della modifica
 
(7 versioni intermedie di 2 utenti non mostrate)
Riga 3: Riga 3:
''Sudo'' è un programma progettato per permettere ad alcuni utenti di eseguire certi comandi come [[root]] (o altro utente).
''Sudo'' è un programma progettato per permettere ad alcuni utenti di eseguire certi comandi come [[root]] (o altro utente).


La filosofia alla base della sua creazione in particolare è stata quella di consentire pieni [[privilegi di amministratore]] a meno comandi possibili, ma permettere ancora di compiere determinate attività di amministrazione. ''Sudo'' è anche un modo efficace per registrare l'attività di root: chi ha usato <code>sudo</code>, con che comando e quando.
La filosofia alla base della sua creazione in particolare è stata quella di consentire pieni [[privilegi di amministrazione]] a meno comandi possibili, ma permettere ancora di compiere determinate attività di amministrazione. ''Sudo'' è anche un modo efficace per registrare l'attività di root: chi ha usato <code>sudo</code>, con che comando e quando.


A partire da Squeeze in Debian <code>sudo</code> è installato e abilitato, se è stato scelto il metapacchetto Desktop durante l'installazione, ma di default nessun utente può usarlo a meno che in fase di installazione si sia disabilitato l'account [[root]].
A partire da Squeeze in Debian <code>sudo</code> è installato e abilitato, se è stato scelto il metapacchetto Desktop durante l'installazione, ma di default nessun utente può usarlo a meno che in fase di installazione si sia disabilitato l'account [[root]].
Riga 15: Riga 15:
Per le ragioni esposte, utilizzare una [[shell]] privilegiata con <code>sudo -i</code> (oppure <code>sudo -s</code>, <code>sudo sh</code>, <code>sudo su</code> e varianti simili) è generalmente sconsigliato perché annulla le caratteristiche di cui sopra. Nel seguito della guida vedremo come disabilitare questa possibilità.
Per le ragioni esposte, utilizzare una [[shell]] privilegiata con <code>sudo -i</code> (oppure <code>sudo -s</code>, <code>sudo sh</code>, <code>sudo su</code> e varianti simili) è generalmente sconsigliato perché annulla le caratteristiche di cui sopra. Nel seguito della guida vedremo come disabilitare questa possibilità.


Si noti che per un sistema con un singolo utente, che è il caso per la maggior parte degli utenti desktop, i benefici di ottenere [[privilegi di amministratore]] con <code>sudo</code> sono inesistenti rispetto all'uso di <code>su</code>, se si permette di eseguire una shell come [[root]]. Sarebbe invece necessario studiare il file di configurazione e personalizzarlo in modo opportuno, restringendone l'uso il più possibile, cercando il giusto compromesso tra sicurezza e comodità d'uso.
Si noti che per un sistema con un singolo utente, che è il caso per la maggior parte degli utenti desktop, i benefici di ottenere [[privilegi di amministrazione]] con <code>sudo</code> sono inesistenti rispetto all'uso di <code>su</code>, se si permette di eseguire una shell come [[root]]. Sarebbe invece necessario studiare il file di configurazione e personalizzarlo in modo opportuno, restringendone l'uso il più possibile, cercando il giusto compromesso tra sicurezza e comodità d'uso.


Per contro <code>sudo</code> di default permette l'esecuzione di comandi successivi senza ulteriore richiesta di password, se entro 15 minuti dall'ultima richiesta.
Di default inoltre <code>sudo</code> permette l'esecuzione di comandi successivi senza ulteriore richiesta di password, se entro 15 minuti (rinnovabili) dall'ultima richiesta e sulla stessa console o terminale.


== Installazione ==
== Installazione ==
Per installare <code>sudo</code>, se non è presente, su Debian basta installare il [[pacchetto]] '''sudo'''. Per esempio con [[apt-get]] e [[privilegi di amministratore]] basta:
Per installare <code>sudo</code>, se non è presente, su Debian basta installare il [[pacchetto]] '''sudo'''. Per esempio con [[apt-get]] e [[privilegi di amministrazione]] basta:
<pre>
<pre>
# apt-get install sudo
# apt-get install sudo
Riga 29: Riga 29:


=== Gruppo sudo ===
=== Gruppo sudo ===
Comunque il file di configurazione di <code>sudo</code> è già preconfigurato per permettere a un utente di eseguire ogni comando come [[privilegi di amministratore|amministratore]], se appartiene al gruppo <code>sudo</code>. Quindi non è necessario apportare modifiche al file di configurazione se si intende permettere al proprio utente di svolgere qualsiasi comando, previa richiesta della propria password.
Comunque il file di configurazione di <code>sudo</code> è già preconfigurato per permettere a un utente di eseguire ogni comando come [[privilegi di amministrazione|amministratore]], se appartiene al gruppo <code>sudo</code>. Quindi non è necessario apportare modifiche al file di configurazione se si intende permettere al proprio utente di svolgere qualsiasi comando, previa richiesta della propria password.


Ciò '''non''' significa però che si ''debba'' aggiungere il proprio utente a tale gruppo, specialmente se l'account [[root]] è attivo. Va fatto soltanto se si vuole utilizzare <code>sudo</code>, con il proprio account, come sostituto per tutte le attività di amministrazione. Non si otterrebbe alcun beneficio in termini di sicurezza, se è anche l'unico account del sistema, si avrebbe solo la comodità di doversi ricordare un'unica password.
Ciò '''non''' significa però che si ''debba'' aggiungere il proprio utente a tale gruppo, specialmente se l'account [[root]] è attivo. Va fatto soltanto se si vuole utilizzare <code>sudo</code>, con il proprio account, come sostituto per tutte le attività di amministrazione. Non si otterrebbe alcun beneficio in termini di sicurezza, se è anche l'unico account del sistema, si avrebbe solo la comodità di doversi ricordare un'unica password.
Riga 40: Riga 40:
È necessario un logout e un nuovo login per risultare iscritti al gruppo.
È necessario un logout e un nuovo login per risultare iscritti al gruppo.


Si può verificare di essere membri di ''sudo'', digitando '''senza''' privilegi di amministratore:
Si può verificare di essere membri di ''sudo'', digitando '''senza''' privilegi di amministrazione:
<pre>
<pre>
$ groups
$ groups
</pre>
</pre>
Che restituisce l'elenco dei gruppi cui appartiene l'utente corrente (<code>pippo</code> nel nostro esempio) in modo simile a questo:
<pre>
pippo users sudo
</pre>
Il nostro utente pippo è effettivamente membro di ''sudo'' solo se tra i vari gruppi elencati compare proprio <code>sudo</code>.


Per rimuoversi invece da tale gruppo, se per esempio il proprio utente si chiama ''pippo'', basta:
Per rimuoversi invece da tale gruppo, se per esempio il proprio utente si chiama ''pippo'', basta:
Riga 49: Riga 54:
# deluser pippo sudo
# deluser pippo sudo
</pre>
</pre>
Prima di questo comando si consiglia di ottenere i [[privilegi di amministratore]] con l'uso di <code>su -</code>, per verificare che l'account [[root]] è attivo prima di rimuoversi dal gruppo.
Prima di questo comando si consiglia di ottenere i [[privilegi di amministrazione]] con l'uso di <code>su -</code>, per verificare che l'account [[root]] è attivo prima di rimuoversi dal gruppo.


==== Disabilitare su e root ====
==== Disabilitare su e root ====
Riga 69: Riga 74:
$ sudo usermod --lock --expiredate 1 root
$ sudo usermod --lock --expiredate 1 root
</pre>
</pre>
Ora è possibile ottenere i [[privilegi di amministratore]] soltanto utilizzando <code>sudo</code>, scrivendolo prima del comando da eseguire come amministratore.
Ora è possibile ottenere i [[privilegi di amministrazione]] soltanto utilizzando <code>sudo</code>, scrivendolo prima del comando da eseguire come amministratore.


Non sarà possibile né effettuare il login come utente ''root'', né utilizzare il comando <code>su</code>.
Non sarà possibile né effettuare il login come utente ''root'', né utilizzare il comando <code>su</code>.
Riga 84: Riga 89:


=== Esempio di configurazione ===
=== Esempio di configurazione ===
Per modificare invece il file di configurazione per sfruttare la flessibilità di <code>sudo</code>, con [[privilegi di amministratore]] digitare:
Per modificare invece il file di configurazione per sfruttare la flessibilità di <code>sudo</code>, con [[privilegi di amministrazione]] digitare:
<pre>
<pre>
# visudo
# visudo
Riga 136: Riga 141:
Le restrizioni operate con '''!''' non sono '''MAI''' realmente efficaci contro malintenzionati se si permette l'uso di ''ALL'', vista la difficoltà di immaginare a priori tutti i comandi possibili. Al limite comunicano che i SUPERUSERS non dovrebbero eseguire tali comandi o equivalenti con lo stesso effetto.
Le restrizioni operate con '''!''' non sono '''MAI''' realmente efficaci contro malintenzionati se si permette l'uso di ''ALL'', vista la difficoltà di immaginare a priori tutti i comandi possibili. Al limite comunicano che i SUPERUSERS non dovrebbero eseguire tali comandi o equivalenti con lo stesso effetto.


Non sarebbe vietato agire su un dispositivo in /dev, caricare nuovi moduli nel kernel, avviare altri interpreti (<code>awk</code>, <code>perl</code>, <code>python</code>, ...), eseguibili con una shell di escape (in grado di avviare una shell, tra cui perfino <code>more</code>, <code>less</code>, <code>w3m</code>, ecc... ) e in generale comandi in grado di avviarne altri (<code>env</code>, <code>find</code>, ...), comandi che avviano più sessioni della shell (<code>screen</code>, <code>tmux</code>, ... ) o emulatori di terminali (<code>xterm</code>, <code>uxterm</code>, <code>lxterm</code>, ...), editor di testo (<code>nano</code>, <code>vi</code>, ...) o qualsiasi comando in grado di alterare il contenuto di un file o i suoi permessi (<code>cp</code>, <code>mv</code>, <code>tee</code>, <code>dd</code>, <code>chmod</code>, <code>chown</code>, ...) per poter modificare <code>/etc/sudoers</code>, <code>/etc/passwd</code>, <code>/etc/shadow</code>, <code>/etc/group</code> o qualunque file (anche uno script d'avvio) utilizzabile per ottenere massimi privilegi.
Non sarebbe vietato agire su un dispositivo in /dev, caricare nuovi moduli nel kernel, avviare altri interpreti (<code>awk</code>, <code>perl</code>, <code>python</code>, ...), eseguibili con una shell di escape (in grado di avviare una shell, tra cui perfino <code>more</code>, <code>less</code>, <code>w3m</code>, ... ) e in generale comandi in grado di avviarne altri (<code>env</code>, <code>find</code>, ...), comandi che avviano più sessioni della shell (<code>screen</code>, <code>tmux</code>, ... ) o emulatori di terminali (<code>xterm</code>, <code>uxterm</code>, <code>lxterm</code>, ...), comandi per alterare la password o l'[[UID]] degli utenti del sistema oppure per crearne altri di privilegiati (<code>passwd</code>, <code>usermod</code>, <code>adduser</code>, <code>useradd</code>, ...), editor di testo (<code>nano</code>, <code>vi</code>, <code>ed</code>, ...) o qualsiasi comando in grado di alterare il contenuto di un file o i suoi permessi (<code>cp</code>, <code>mv</code>, <code>sed</code>, <code>tee</code>, <code>dd</code>, <code>chmod</code>, <code>chown</code>, ...) per poter modificare <code>/etc/sudoers</code>, <code>/etc/passwd</code>, <code>/etc/shadow</code>, <code>/etc/group</code> o qualunque file (anche uno script d'avvio) utilizzabile per ottenere massimi privilegi.


Se anche tutti questi venissero vietati, e si noti che si impedirebbero molti comandi utili in situazioni generali, sarebbe sempre possibile fare copie di una shell con altri nomi e perfino creare nuovi eseguibili che modifichino file con [[privilegi di amministratore]].
Se anche tutti questi e tutti quelli utilizzabili per gli stessi exploit venissero vietati, e si noti che si impedirebbero molti comandi utili in situazioni generali, sarebbe sempre possibile fare copie di una shell con altri nomi e creare nuovi eseguibili, perfino banali script, che modificano file con [[privilegi di amministrazione]] o avviano una [[shell]] privilegiata.


'''L'unico modo''' per restringere le attività che un utente può eseguire come amministratore è limitarlo a una '''lista predeterminata''' di eseguibili, secondo un approccio di tipo ''whitelist'' anziché ''blacklist'', valutando singolarmente che non siano sfruttabili anche per altre azioni, come per esempio eseguire una shell o alterare il sistema in modo arbitrario.
'''L'unico modo''' per restringere le attività che un utente può eseguire come amministratore è limitarlo a una '''lista predeterminata''' di eseguibili, secondo un approccio di tipo ''whitelist'' anziché ''blacklist'', valutando singolarmente che non siano sfruttabili anche per altre azioni, come per esempio eseguire una shell o alterare il sistema in modo arbitrario.


E si noti che perfino rimuovendo ''ALL'' il solo <code>dpkg</code>, utilizzabile dagli ADMIN, è in grado di installare software esterno a Debian, creabile da chiunque se in forma di [[pacchetto|pacchetto deb]], e può essere quindi sfruttato per ottenere pieni privilegi di amministratore. E anche i comandi <code>apt-get</code> e <code>aptitude</code> durante un aggiornamento, in presenza di configurazioni cambiate, possono permettere di accedere a una shell con permessi di [[root]].
E si noti che perfino rimuovendo ''ALL'' il solo <code>dpkg</code>, utilizzabile dagli ADMIN, è in grado di installare software esterno a Debian, creabile da chiunque se in forma di [[pacchetto|pacchetto deb]], e può essere quindi sfruttato per ottenere pieni privilegi di amministrazione. E anche i comandi <code>apt-get</code> e <code>aptitude</code> durante un aggiornamento, in presenza di configurazioni cambiate, possono permettere di accedere a una shell con permessi di [[root]].


Questo per dire che a volte la sicurezza ottenuta da tali file di configurazione, pur riducendo di molto gli usi consentiti, è soltanto apparente senza un'attenta valutazione delle conseguenze per ogni comando permesso. E spesso, come nell'esempio precedente, non è possibile impedirne l'abuso senza togliere anche la possibilità di svolgere un'attività di amministrazione, il che non è sempre accettabile. Le regole scritte nel file di configurazione in questi casi servono a comunicare a un amministratore minore le funzioni che è autorizzato a svolgere, che possono essere monitorate tramite i log delle attività, predisponendo dei sistemi di protezione (hardware o tramite ''Mandatory Access Control'') che ne garantiscano l'integrità.
Questo per dire che a volte la sicurezza ottenuta da tali file di configurazione, pur riducendo di molto gli usi consentiti, è soltanto apparente senza un'attenta valutazione delle conseguenze per ogni comando permesso. E spesso, come nell'esempio precedente, non è possibile impedirne l'abuso senza togliere anche la possibilità di svolgere un'attività di amministrazione, il che non è sempre accettabile. Le regole scritte nel file di configurazione in questi casi servono a comunicare a un amministratore minore le funzioni che è autorizzato a svolgere, che possono essere monitorate tramite i log delle attività, predisponendo dei sistemi di protezione (hardware o tramite ''Mandatory Access Control'') che ne garantiscano l'integrità.
Riga 162: Riga 167:
</pre>
</pre>


Si ricordi che, di default, ogni successivo comando '''non''' richiederà nuovamente la password, finché non saranno passati 15 minuti dall'ultima richiesta. Si possono invalidare le credenziali memorizzate, comportando la richiesta di password per i comandi successivi, eseguendo manualmente:
Si ricordi che, di default, ogni successivo comando sulla stessa console o terminale '''non''' richiederà nuovamente la password, finché non saranno passati 15 minuti dall'ultima richiesta. Si possono invalidare le credenziali memorizzate, comportando la richiesta di password per i comandi successivi, eseguendo manualmente:
<pre>$ sudo -k</pre>
<pre>$ sudo -k</pre>
e si possono personalizzare i minuti di timeout, modificando con <code>visudo</code> il file di configurazione per aggiungere in cima al file:
oppure al contrario, se non sono ancora scadute, si possono validare per altri 15 minuti dall'esecuzione di:
<pre>$ sudo -v</pre>
 
Per personalizzare i minuti di timeout si deve modificare con <code>visudo</code> il file di configurazione per aggiungere in cima al file:
<pre>Defaults timestamp_timeout=MINUTI</pre>
<pre>Defaults timestamp_timeout=MINUTI</pre>


Riga 183: Riga 191:
| Verificata_da =
| Verificata_da =
: [[Utente:Stemby|Stemby]]
: [[Utente:Stemby|Stemby]]
: [[Utente:HAL 9000|HAL 9000]] 14:12, 6 set 2014 (CEST)
: [[Utente:HAL 9000|HAL 9000]] 14:03, 12 apr 2015 (CEST)
| Estesa_da =
| Estesa_da =
: [[Utente:Stemby|Stemby]]
: [[Utente:Stemby|Stemby]]
Riga 191: Riga 199:


[[Categoria:Shell]]
[[Categoria:Shell]]
[[Categoria:Monitoraggio]]
[[Categoria:Debian e sicurezza]]
[[Categoria:Debian e sicurezza]]

Versione attuale delle 18:02, 4 mag 2024

Debian-swirl.png Versioni Compatibili

Tutte le versioni supportate di Debian

Introduzione

Sudo è un programma progettato per permettere ad alcuni utenti di eseguire certi comandi come root (o altro utente).

La filosofia alla base della sua creazione in particolare è stata quella di consentire pieni privilegi di amministrazione a meno comandi possibili, ma permettere ancora di compiere determinate attività di amministrazione. Sudo è anche un modo efficace per registrare l'attività di root: chi ha usato sudo, con che comando e quando.

A partire da Squeeze in Debian sudo è installato e abilitato, se è stato scelto il metapacchetto Desktop durante l'installazione, ma di default nessun utente può usarlo a meno che in fase di installazione si sia disabilitato l'account root.

Perché sudo

Usare sudo in alcune circostanze è meglio (più sicuro) che aprire una sessione come root, in particolare per i seguenti motivi:

  • Non c'è bisogno di password di root, ma sudo richiede la password dell'utente corrente. È fondamentale nel caso si debba permettere a più persone di svolgere attività di amministrazione, senza bisogno di condividere la stessa password.
  • In una shell i comandi vengono eseguiti come utente corrente (cioè non privilegiato) e per impostazione predefinita non viene avviata una shell privilegiata, permettendo di evitare errori. Solo i comandi preceduti da sudo vengono eseguiti come root.
  • Verifica/registrazione: quando un comando è eseguito con sudo il nome dell'utente e il comando sono registrati.

Per le ragioni esposte, utilizzare una shell privilegiata con sudo -i (oppure sudo -s, sudo sh, sudo su e varianti simili) è generalmente sconsigliato perché annulla le caratteristiche di cui sopra. Nel seguito della guida vedremo come disabilitare questa possibilità.

Si noti che per un sistema con un singolo utente, che è il caso per la maggior parte degli utenti desktop, i benefici di ottenere privilegi di amministrazione con sudo sono inesistenti rispetto all'uso di su, se si permette di eseguire una shell come root. Sarebbe invece necessario studiare il file di configurazione e personalizzarlo in modo opportuno, restringendone l'uso il più possibile, cercando il giusto compromesso tra sicurezza e comodità d'uso.

Di default inoltre sudo permette l'esecuzione di comandi successivi senza ulteriore richiesta di password, se entro 15 minuti (rinnovabili) dall'ultima richiesta e sulla stessa console o terminale.

Installazione

Per installare sudo, se non è presente, su Debian basta installare il pacchetto sudo. Per esempio con apt-get e privilegi di amministrazione basta:

# apt-get install sudo

Configurazione

Per modificare il file di configurazione, anziche modificare direttamente /etc/sudoers, è consigliato l'uso del comando visudo, che effettua anche un controllo sulla sintassi utilizzata. Ed è l'unico modo per trarre beneficio dalla flessibilità permessa da sudo, in genere a spese della comodità d'uso.

Gruppo sudo

Comunque il file di configurazione di sudo è già preconfigurato per permettere a un utente di eseguire ogni comando come amministratore, se appartiene al gruppo sudo. Quindi non è necessario apportare modifiche al file di configurazione se si intende permettere al proprio utente di svolgere qualsiasi comando, previa richiesta della propria password.

Ciò non significa però che si debba aggiungere il proprio utente a tale gruppo, specialmente se l'account root è attivo. Va fatto soltanto se si vuole utilizzare sudo, con il proprio account, come sostituto per tutte le attività di amministrazione. Non si otterrebbe alcun beneficio in termini di sicurezza, se è anche l'unico account del sistema, si avrebbe solo la comodità di doversi ricordare un'unica password.

Se è questo il caso, per aggiungere il proprio utente (per esempio pippo) al gruppo sudo va eseguito:

# adduser pippo sudo

È necessario un logout e un nuovo login per risultare iscritti al gruppo.

Si può verificare di essere membri di sudo, digitando senza privilegi di amministrazione:

$ groups

Che restituisce l'elenco dei gruppi cui appartiene l'utente corrente (pippo nel nostro esempio) in modo simile a questo:

pippo users sudo

Il nostro utente pippo è effettivamente membro di sudo solo se tra i vari gruppi elencati compare proprio sudo.

Per rimuoversi invece da tale gruppo, se per esempio il proprio utente si chiama pippo, basta:

# deluser pippo sudo

Prima di questo comando si consiglia di ottenere i privilegi di amministrazione con l'uso di su -, per verificare che l'account root è attivo prima di rimuoversi dal gruppo.

Disabilitare su e root

Se si modifica la configurazione di default per poter utilizzare sudo con tutti i comandi, si consiglia che almeno sia l'unico modo per diventare amministratori, nel caso l'account root esista.

Per disabilitare soltanto l'uso di su, senza disabilitare l'account di root, è sufficiente:

$ sudo nano /etc/pam.d/su

E decommentare (rimuovere il carattere # iniziale) dalla linea:

#auth       required pam_wheel.so

dopodiché salvare premendo Ctrl-o e uscire con Ctrl-x. Nessuno potrà utilizzarlo, se non i membri del gruppo root (oppure wheel, se creato), ovvero soltanto lo stesso amministratore.

Per ripristinare tutto è sufficiente annullare le proprie modifiche, ripetendo il comando precedente e ricommentando con # la riga:

auth       required pam_wheel.so

Se si vuole invece disabilitare l'account di root, digitare il seguente comando:

$ sudo usermod --lock --expiredate 1 root

Ora è possibile ottenere i privilegi di amministrazione soltanto utilizzando sudo, scrivendolo prima del comando da eseguire come amministratore.

Non sarà possibile né effettuare il login come utente root, né utilizzare il comando su.

Per riattivare root, permettendo nuovamente sia il login che l'utilizzo di su, dare invece il seguente comando:

$ sudo usermod --unlock --expiredate "" root

Si noti che è necessario anche assegnargli una password, se l'account non era mai stato attivo o ne fosse sprovvisto:

$ sudo passwd

Esempio di configurazione

Per modificare invece il file di configurazione per sfruttare la flessibilità di sudo, con privilegi di amministrazione digitare:

# visudo

Un esempio di configurazione può essere questo:

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults        env_reset, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Configurazione di default per root
# L'utente root ha i permessi su ogni comando
root    ALL=(ALL) ALL

# Definisco un alias contenente una lista
# di utenti amministratori del server
User_Alias      ADMINS = utente1, utente2, utente3
User_Alias      SUPERUSERS = utente4, utente5

# Definisco eventuali alias per gli utenti

# Definisco degli alias per i comandi di sistema
Cmnd_Alias      SHUTDOWN = /sbin/shutdown, /sbin/reboot, /sbin/halt
Cmnd_Alias      PKGMGMT = /usr/bin/dpkg, /usr/bin/apt-get, /usr/bin/aptitude

# Definisco degli alias per i comandi che voglio impedire
Cmnd_Alias   NSHELLS = /bin/sh, /bin/bash, /bin/dash
Cmnd_Alias   NSU = /bin/su
Cmnd_Alias   NVISUDO = /usr/sbin/visudo

# Definisco eventuali privilegi degli utenti

# Gli utenti del gruppo ADMINS possono gestire i pacchetti deb e riavviare
# il server
ADMINS ALL = PKGMGMT, SHUTDOWN

# Gli utenti del gruppo SUPERUSERS possono fare tutto e impersonare qualsiasi
# utente, tranne eseguire una shell di root, usare l'hack "sudo su" e
# modificare la configurazione di sudo
SUPERUSERS ALL = ALL, !NSHELLS, !NSU, !NVISUDO

Valutazioni di sicurezza

Le restrizioni operate con ! non sono MAI realmente efficaci contro malintenzionati se si permette l'uso di ALL, vista la difficoltà di immaginare a priori tutti i comandi possibili. Al limite comunicano che i SUPERUSERS non dovrebbero eseguire tali comandi o equivalenti con lo stesso effetto.

Non sarebbe vietato agire su un dispositivo in /dev, caricare nuovi moduli nel kernel, avviare altri interpreti (awk, perl, python, ...), eseguibili con una shell di escape (in grado di avviare una shell, tra cui perfino more, less, w3m, ... ) e in generale comandi in grado di avviarne altri (env, find, ...), comandi che avviano più sessioni della shell (screen, tmux, ... ) o emulatori di terminali (xterm, uxterm, lxterm, ...), comandi per alterare la password o l'UID degli utenti del sistema oppure per crearne altri di privilegiati (passwd, usermod, adduser, useradd, ...), editor di testo (nano, vi, ed, ...) o qualsiasi comando in grado di alterare il contenuto di un file o i suoi permessi (cp, mv, sed, tee, dd, chmod, chown, ...) per poter modificare /etc/sudoers, /etc/passwd, /etc/shadow, /etc/group o qualunque file (anche uno script d'avvio) utilizzabile per ottenere massimi privilegi.

Se anche tutti questi e tutti quelli utilizzabili per gli stessi exploit venissero vietati, e si noti che si impedirebbero molti comandi utili in situazioni generali, sarebbe sempre possibile fare copie di una shell con altri nomi e creare nuovi eseguibili, perfino banali script, che modificano file con privilegi di amministrazione o avviano una shell privilegiata.

L'unico modo per restringere le attività che un utente può eseguire come amministratore è limitarlo a una lista predeterminata di eseguibili, secondo un approccio di tipo whitelist anziché blacklist, valutando singolarmente che non siano sfruttabili anche per altre azioni, come per esempio eseguire una shell o alterare il sistema in modo arbitrario.

E si noti che perfino rimuovendo ALL il solo dpkg, utilizzabile dagli ADMIN, è in grado di installare software esterno a Debian, creabile da chiunque se in forma di pacchetto deb, e può essere quindi sfruttato per ottenere pieni privilegi di amministrazione. E anche i comandi apt-get e aptitude durante un aggiornamento, in presenza di configurazioni cambiate, possono permettere di accedere a una shell con permessi di root.

Questo per dire che a volte la sicurezza ottenuta da tali file di configurazione, pur riducendo di molto gli usi consentiti, è soltanto apparente senza un'attenta valutazione delle conseguenze per ogni comando permesso. E spesso, come nell'esempio precedente, non è possibile impedirne l'abuso senza togliere anche la possibilità di svolgere un'attività di amministrazione, il che non è sempre accettabile. Le regole scritte nel file di configurazione in questi casi servono a comunicare a un amministratore minore le funzioni che è autorizzato a svolgere, che possono essere monitorate tramite i log delle attività, predisponendo dei sistemi di protezione (hardware o tramite Mandatory Access Control) che ne garantiscano l'integrità.

Va considerato comunque che utilizzare una lista ridotta di comandi, per quanto sia a volte possibile abusarli per ottenere pieni privilegi ed eseguire qualsiasi comando, almeno riduce sempre le possibilità di eseguire inavvertitamente del software malevolo. E le restrizioni operate con ALL, per quanto sempre facilmente aggirabili, disabilitano almeno le opzioni di sudo che potrebbero essere usate per abitudine, rendendo più chiara l'analisi dei log e l'individuazione di possibili attività anomale.

Esempio di sessione sudo

Una tipica sessione di sudo si presenta così:

utente1@server $ sudo comando

Ci auguriamo tu abbia ricevuto la notifica dall'amministratore locale di sistema. Che si riduce solitamente a queste tre cose:

    #1) Rispetta la privacy altrui.
    #2) Pensa prima di digitare.
    #3) Da grandi poteri derivano grandi responsabilità.

[sudo] password for utente1:

Si ricordi che, di default, ogni successivo comando sulla stessa console o terminale non richiederà nuovamente la password, finché non saranno passati 15 minuti dall'ultima richiesta. Si possono invalidare le credenziali memorizzate, comportando la richiesta di password per i comandi successivi, eseguendo manualmente:

$ sudo -k

oppure al contrario, se non sono ancora scadute, si possono validare per altri 15 minuti dall'esecuzione di:

$ sudo -v

Per personalizzare i minuti di timeout si deve modificare con visudo il file di configurazione per aggiungere in cima al file:

Defaults timestamp_timeout=MINUTI

Nel caso dopo l'esecuzione di un comando con sudo si ricevesse la risposta:

Spiacente, all'utente utente1 non è consentito eseguire '/usr/bin/comando' come root su localhost

significa che l'utente non ha i permessi, in base al file di configurazione creato, di eseguire tale comando.

File di log

Il comando sudo logga tutte le sue attività nel file /var/log/auth.log

Sitografia




Guida scritta da: Ferdybassi 12:42, 6 nov 2010 (CET) Swirl-auth60.png Debianized 60%
Estesa da:
Stemby
HAL 9000
Verificata da:
Stemby
HAL 9000 14:03, 12 apr 2015 (CEST)

Verificare ed estendere la guida | Cos'è una guida Debianized