Guida a Sudo: differenze tra le versioni

{{Stub}}

La stragrande maggioranza degli utenti che utilizza sudo lo fa in maniera sbagliata e, tipicamente, è composta da utenti provenienti da una famosa distribuzione derivata che si affacciano per la prima volta a Debian.<br/>

Purtroppo oggi la stessa famosa distribuzione derivata installa sudo di default con il meritevole intento di 'semplificare' l'interazione uomo-macchina; il risultato, però, ha portato a conseguenza indesiderate:

=== Mi serve sudo? ===

Dopo questa premessa, torniamo a sudo per rispondere alla domanda: "Mi serve sudo?"<br/>

Su una macchina desktop monoutente (il computer di casa, il portatile, il PC dell'ufficio), sudo è inutile. Esiste il comando ''su''' (e le sue interfacce grafiche ''gksu'' e ''kdesu'') che permette di eseguire comandi con i permessi di root (o, se presente, di qualsiasi altro utente) in tutta sicurezza e, soprattutto, senza dover modificare alcun file di configurazione. Questo previene errori dovuti a configurazioni sbagliate.

Su una macchina server, invece, il comando sudo è a volte necessario se non indispensabile.<br/>

Vi è anche una terza di tipologia di sistemi a cui si rivolge sudo: le macchine desktop gestite da utenti consapevoli che utilizzano sudo per operazioni ben definite e che modificano correttamente il file <code>sudoers</code>.

Un breve elenco di operazioni da evitare nell'uso e configurazione di sudo.

;'''ALL : ALL'''

:Il primo errore consiste nell'inserire la riga:<pre>utente ALL:ALL</pre>oppure la riga:<pre>utente ALL = (ALL) ALL</pre>In questo modo si dà il permesso a ''utente'' di fare qualunque cosa previo inserimento della propria password.<br/>Ma perché ricorrere a tale soluzione quando si può essere ugualmente distruttivi con...

;Aggiungere il proprio utente al gruppo sudo

:Altro errore è aggiungere il proprio utente al gruppo sudo:<pre># adduser nome_utente sudo</pre>ed effettuare un logout/login.<br/><br/>Poiché in <code>/etc/sudoers</code> esiste la riga:<pre>%sudo ALL = (ALL):ALL</pre>l'effetto è permettere agli utenti del gruppo sudo di eseguire qualsiasi comando (ultimo ALL) da qualsiasi host (primo ALL) e con qualsiasi credenziale (ALL tra parentesi).<br/>Si otterrà effettivamente il funzionamento di sudo, ma a che prezzo?<br/>L'utente può eseguire qualunque comando semplicemente inserendo la propria password. Quindi:* cade la distinzione tra utente normale e amministratore * si permette a chiunque conosca la password, di eseguire tutti i comandi di sistema<br/>La conclusione è ovvia: state utilizzando Debian come se fosse Win95. Se qualcuno viene in possesso della vostra password utente, potrà fare qualunque cosa senza nemmeno doversi affannare a cercare la password di root.<br/>In pratica siete come dei direttori di banca che, nel portachiavi, portano in giro una chiave che apre sia la porta di ingresso alla banca che la cassaforte.

:Se modificate frequentemente i file di sistema, potrebbe sorgere l'illusoria esigenza di dover installare sudo.<br/>Qui l'errore è concettuale: se modificate spesso i file di sistema, c'è qualcosa che non va. A meno che non siate amministratori di un server.<br/>La soluzione non è installare sudo, ma capire il perché di tante modifiche su una macchina Debian che non necessita di interventi continui come root. Spesso, infatti, l'intervento come root si riduce ad una prima configurazione iniziale (che resta poi praticamente invariata) e a successive operazioni di installazione, rimozione e aggiornamento di pacchetti (per cui esistono programmi a interfaccia grafica o il comando su).

:Un errore molto meno marchiano è utilizzare sudo con programmi che permettono l'escape della shell, ossia che consentono, una volta eseguiti, di poter avviare una shell.<br/>Consideriamo la seguente riga in <code>/etc/sudoers</code>:<pre>pippo ALL = /usr/bin/vim /etc/apt/sources.list</pre>in buona fede si potrebbe pensare di concedere all'utente pippo la sola modifica del file <code>/etc/apt/sources.list</code> attraverso Vim. Malauguratamente Vim, e altri programmi, permettono di eseguire un shell (vedere qui). Per cui l'utente pippo, un volta eseguito il comando:<pre>$ sudo vim /etc/apt/sources.list</pre>potrà, dopo aver inserito la propria password, aprire una shell con i permessi di root e, subito dopo, eseguire qualunque comando con i permessi di superutente; esattamente ciò che non vogliamo.<br/>La soluzione è modificare il file sudoers così:<pre>pippo localhost = NOEXEC : /usr/bin/vim /etc/apt/sources.list</pre>o utilizzare altro editor (nano) che non permetta l'escape della shell.

* Non installare sudo su macchine desktop.<br/>Avvalersi, piuttosto, degli strumenti alternativi (grafici e testuali) che Debian mette a disposizione.

* Se si decide di utilizzare sudo, documentarsi sul suo funzionamento e la sua configurazione.<br/>Documentarsi anche sul funzionamento di ogni programma che si è deciso di avviare attraverso sudo.

* Valutare attentamente i vantaggi e gli svantaggi a cui si va incontro utilizzando sudo.

e poi rimuovere il proprio utente dal gruppo sudo:

Questo disabilita sudo per "nome_utente" e permette di configurarlo successivamente, se si vuole, con sicurezza e precisione maggiori. Oltre che con la piena consapevolezza delle operazioni che ci si accinge a svolgere.

Se ci si dovesse chiedere del perché Debian non installi sudo di default come altre famose distribuzioni derivate, la risposta è semplice: Debian ha una configurazione di base fortemente orientata alla sicurezza e possiede già di default tutti gli strumenti necessari e coerenti per amministrare la propria macchina.

La configurazione di sudo si ottiene con la modifica del file <code>/etc/sudoers</code> oppure con la creazione di file di configurazione nella directory <code>/etc/sudoers.d/</code> .

Per modificare il file sudoers c'è un'unica strada, utilizzare da root il comando:

Le righe in grassetto sono quelle significative. I commenti (righe che iniziano con #) o le righe vuote non contribuiscono alla configurazione di sudo ma sono comunque importanti per la leggibilità del file.<br/>

Prestare attenzione al fatto che aggiornamenti del pacchetto sudo potrebbero chiedere di sovrascrivere questo file.<br/>

In caso si debba scrivere un elevato numero di righe, si può far uso della directory /etc/sudoers.d/ in cui è possibile creare tutti i file che si ritengono necessari per configurare sudo. Questi verranno visti in sequenza come un unico file di configurazione.

* Il file sudoers viene comunque e sempre letto per primo

* Affinché questi file possano essere considerati come file di configurazione, è necessario che sia presente in /etc/sudoers la riga:<pre>#includedir /etc/sudoers.d</pre>

* Scegliere nomi significativi (07alias_comandi_per_l_utente_pippo è preferibile a 07config).

* Le configurazioni presenti in un file possono sovrascrivere identiche configurazioni contenute in un file che lo precede. Se possibile, fare in modo che le configurazioni comuni siano contenute nel primo file o nel file sudoers.

* A differenza del file sudoers, è possibile creare e modificare questi file con un editor grafico attraverso gksu o kdesu<pre>$ gksu gedit /etc/sudoers.d/01pippo</pre>

* Tutti i file presenti in questa directory non saranno sovrascritti o cancellati da futuri aggiornamenti del pacchetto sudo

Riprendiamo il file /etc/sudoers per analizzarne la struttura. Possiamo vedere che esistono quattro sezioni.

'''Direttiva #includedir (TODO #include)'''<br/>

Quest'ultima sezione indica la directory in cui leggere eventuali e ulteriori file di configurazione di sudo. Andrebbe lasciata in fondo al file ed, eventualmente, modificata specificando altra directory se si hanno esigenze particolari.

Iniziamo ad analizzare gli alias, inizialmente non specificati. Questo indica che, in sostanza, non sono strettamente necessari per configurare sudo, anche se il loro ruolo diventa fondamentale quando il numero di linee inizia a crescere ed è facile ritrovarsi nella sgradevole situazione di perdere tempo nell'analizzare i file di configurazione.

* I comandi devono essere scritti esattamente insieme al loro path assoluto (whereis nomecomando per trovarlo)

* È possibile inserire anche il percorso assoluto di una directory, questo indicherà che potranno essere eseguiti con sudo tutti i programmi contenuti in quella directory ma non nelle sottodirectory. Ad esempio con:

è possibile eseguire con sudo tutto ciò che si trova in /bin/

Questa lista può essere  composta da nomi utente, gruppi (preceduti dal carattere "%"), [[UID]] (preceduti dal carattere "#"), gruppi di rete (preceduti dal carattere "+") o altri alias di tipo Runas_Alias e specifica con i permessi di quale utente deve essere eseguito un comando attraverso sudo.

se l'utente topolino fa parte del gruppo adm.

Eccoci giunti al cuore del file sudoers: le righe che indicano in che modo e con quali comandi è possibile invocare sudo.<br/>

- L'utente a cui è consentito eseguire sudo<br/>

- L'host da cui si esegue sudo<br/>

La prima parola indica chi può eseguire sudo. Questa può essere uno username, un gruppo (preceduto da %), un netgroup (preceduto da "+") o un alias di tipo User_Alias.<br/>

Di default a tutti viene chiesta la propria password. Nel caso l'utente non sia abilitato ad eseguire un comando con sudo:

Come si vede chiaramente, di default sudo cerca di eseguire il comando con i permessi di root (che è poi il compito per cui viene utilizzato).

La seconda parola specifica il nome dell'host da cui è permesso eseguire sudo. Possono essere specificati anche indirizzi IP o indirizzi di rete con submask. Vedi ...<br/>

La parola "ALL" indica che gli utenti potranno eseguire sudo da qualsiasi host.<br/>

Lo scopo di questa voce è chiaro, magari si vuol consentire a pippo di eseguire sudo solo da una macchina della rete locale:

(TODO: permessi utente/gruppo tag comando)

Visualizza un avvertimento prima che un utente esegua un comando attraverso sudo. I possibili valori sono:<br/>

always = l'avvertimento viene sempre visualizzato<br/>

never = l'avvertimento non viene mai visualizzato<br/>

once = l'avvertimento viene visualizzato solo la prima volta che un utente esegue sudo

'''passprompt (TODO: andata a capo)'''<br/>

-%p : l'utente la cui password viene richiesta (%p può essere diverso dall'utente che esegue sudo)<br/>

-%u : l'utente che esegue il comando attraverso sudo<br/>

<pre>Defaults passprompt="%u sta utilizzando sudo su %H. Il comando verrà eseguito con i permessi di %U. Inserisci la password di %p"</pre>

Per il file di log per sudo, di default, viene utilizzato <code>/var/log/syslog</code>. È sempre conveniente avere un log separato e specifico in cui leggere eventuali messaggi di errore (o minacce alla sicurezza del sistema attraverso sudo) senza rischiare di perderli nella lettura di un file di log più generale. Utilizzare [[logrotate]] per evitare che il file di log cresca troppo.<br/>

e poi, in /etc/sudoers :

<pre>Defaults logfile="/var/log/sudo.log"

Nel file di log (diverso da syslog) viene specificato l'host. Di default questa opzione è disabilitata, per abilitarla:

Tutti gli input dell'utente attraverso una sessione sudo verranno loggati nella directory <code>/var/log/sudo-io/</code>. Ciascun file di questa directory ha un nome univoco in base al TSID (Terminal Session ID).<br/>

Questa opzione è disabilita di default. Per abilitarla:

<pre>Defaults log_input</pre>

TUTTI gli input degli utenti saranno loggati in chiaro, anche le password eventualmente digitate durante una sessione sudo. I log si trovano in <code>/var/log/sudo-io/nn/nn/nn/ttyin</code> in formato compresso (nn sono stringhe di numeri-cifre), ad esempio per leggere l'input della sessione con TSID=000001:

'''log_output (TODO:CAMBIARE LA DATA)'''<br/>

Tutti i messaggi visualizzati a schermo in una sessione sudo saranno loggati nella directory <code>/var/log/sudo-io/</code>, anche questi in base al TSID.<br/>

Questa opzione è disabilita di default. Per abilitarla:

Per visualizzare questi log si può utilizzare il comodo comando "sudoreplay" che permette di replicare esattamente tutto ciò che è stato visualizzato a schermo durante la sessione sudo.

per ottenere maggiori informazioni sul funzionamento di sudoreplay.

L'utente deve inserire una password per poter utilizzare sudo (di default: la propria password). Questo comportamento può essere bypassato attraverso i tag PASSWD e NOPASSWD.<br/>

Di default è 3. Ciò vuol dire che si hanno tre tentativi per inserire correttamente la password prima che sudo termini con questo messaggio d'errore:

È il numero di minuti trascorsi i quali il prompt di immissione della password viene chiuso. Di default questo valore è 0, cioè sudo rimane indefinitivamente in attesa della password.

Di default questo valore è 15. Ciò vuol dire che, dal momento in cui si inserisce correttamente una password, passeranno quindici minuti senza che sudo la richieda ancora.

Per cambiarla:

Se viene inserita una password sbagliata, verrà visualizzato un messaggio di "insulto" anziché il messaggio di errore di default o ciò che è definito in badpass_message.<br/>

I messaggi sono in inglese e non particolarmente offensivi; se volete messaggi in italiano o volete andarci giù pesante con le offese, ricompilatevi sudo con le modifiche apportate.

Attiva il feedback per ogni tasto premuto durante l'inserimento della password. Tipicamente un asterisco. (TODO: come è impostato?)

Con questa opzione viene chiesta la password di root anziché la password dell'utente che esegue sudo.<br/>

Di default è disabilitata ed è fortemente sconsigliato abilitarla; sudo viene utilizzato proprio per evitare di digitare la password di root.

- all: la password non viene chiesta solo se tutte le entries che riguardano l'utente contengono il tag NOPASSWD<br/>

. any: la password non viene chiesta solo se almeno una entries che riguarda l'utente contiene il tag NOPASSWD<br/>

- always: la password viene sempre chiesta<br/>

- never: la password non viene mai chiesta. "listpw=never" è equivalente a "!listpw"<br/>

Come il precedente ma con listpw=all . Questa volta la password viene chiesta perché non tutte le entries hanno il tag NOPASSWD.

Il valore di default per questa opzione è "any". Il valore "never" può essere utilizzato dagli amministratori per impedire che, senza l'inserimento di una password, qualcuno possa risalire ai comandi eseguibili da un utente attraverso sudo.

EMAIL /DA CONTROLLARE CON ESEMPI CONCRETI

(TODO: gli escpape %)

(TODO: posta locale)

L'indirizzo da cui verrà inviata l'email. Di default è l'indirizzo dell'utente che esegue sudo.

(TODO)

Viene inviata una email ogni volta che un utente esegue sudo. Di default questa opzione è disabilitata. Per abilitarla:

Viene inviata una email se l'utente è abilitato ad eseguire sudo ma non sull'host specificato. Questa opzione è disabilitata di default. Per abilitarla:

<pre>Defaults mail_no_host

L'email verrà inviata se l'utente pippo si collegherà dall'host sds.dsds.sds e proverà ad eseguire:

'''mail:no_perms'''<br/>

Viene inviata una email se l'utente ha i permessi di eseguire comandi attraverso sudo ma cerca di eseguire altri comandi non consentiti. Di default questa opzione è disabilitata.

ma non se pippo prova ad eseguire lo stesso comando ma con sudoers impostato in questo modo:

Viene inviata una email se l'utente che esegue sudo non è presente nel file sudoers. Questa opzione è abilitata di default. Per disabilitarla (sconsigliato):

a meno che non sia abilitata mail_no_perms .

in modo da rendersi conto di come viene utilizzato sudo dagli utenti della propria rete e, quindi, apportare le opportune correzioni.

 

Supponiamo che l'utente gambadilegno abbia una variabile d'ambiente così definita nel proprio .bashrc :

La modifica di file di sistema (normalmente riservata a root) è sicuramente il compito più diffuso per cui viene utilizzato <pre>sudo</pre>.<br/>