Guida a Sudo: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
(nuova guida)
 
Nessun oggetto della modifica
 
(41 versioni intermedie di 4 utenti non mostrate)
Riga 1: Riga 1:
{Stub}
{{Versioni compatibili}}
== Caveat ==
== Prima di iniziare ==
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.
<!--
* SEZIONE COMMENTATA
=== Caveat ===
La stragrande maggioranza degli utenti che utilizza <code>sudo</code> 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/>
È necessario, quindi, spender poche parole in proposito.
È necessario, quindi, spender poche parole in proposito.


Debian, durante l'installazione, chiede di inserire due password: una per l'utente root e l'altra per l'utente che normalmente utilizza la macchina (e che non ha abitualmente la necessità di eseguire comandi con i permessi di root).
Debian, durante l'installazione, chiede di creare due password: una per l'utente [[root]] e l'altra per l'utente che normalmente utilizza la macchina (e che non ha abitualmente la necessità di eseguire comandi con i permessi di root).<br/>
Questa distinzione non è un capriccio degli sviluppatori e neanche una forma di sadismo per obbligarci nell'ardua impresa di memorizzare due password, è, invece, un forma minima di sicurezza per mantenere separati i compiti di amministrazione (modifica dei file di sistema che richiedono i permessi di root) dalle normali attività legate all'uso della macchina (lavoro, studio, ascolto di file musicali, navigazione in Internet).
Questa distinzione non è un capriccio degli sviluppatori e neanche una forma di sadismo per obbligarci nell'"ardua impresa" di memorizzare due password; è, invece, un forma minima di sicurezza per mantenere separati i compiti di amministrazione (modifica dei file di sistema che richiedono i permessi di root) dalle normali attività legate all'uso della macchina (lavoro, studio, ascolto di file musicali, navigazione in Internet).


Questa separazione è di fondamentale importanza  
Questa separazione è di fondamentale importanza<br/>
- per evitare accidentali modifiche a file di sistema
- per evitare accidentali modifiche a file di sistema<br/>
- per accrescere la consapevolezza in ciascuna persona sulle operazioni che sta svolgendo
- per accrescere la consapevolezza in ciascuna persona sulle operazioni che sta svolgendo


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:
Purtroppo oggi la stessa famosa distribuzione derivata installa <code>sudo</code> di default con il meritevole intento di 'semplificare' l'interazione uomo-macchina; il risultato, però, ha portato a conseguenza indesiderate:
1 non si ha la percezione di cosa si sta facendo
* non si ha la percezione di cosa si sta facendo
2 non si ha la percezione della distinzione amministratore - utente
* non si ha la percezione della distinzione amministratore - utente
3 non si ha la percezione di sé nei confronti della macchina
* non si ha la percezione di sé nei confronti della macchina
Tutto questo, per un utente Debian, è inaccettabile.
Tutto questo, per un utente Debian, è inaccettabile.
-->


== MI SERVE SUDO? ==
=== Mi serve <code>sudo</code>? ===
Dopo questa premessa, torniamo a sudo per rispondere alla domanda: "Mi serve sudo?"
<!-- Dopo questa premessa, torniamo a <code>sudo</code> per rispondere alla domanda: "Mi serve <code>sudo</code>?"<br/> -->
La risposta è, come sempre, "dipende".
La risposta è, come sempre, "dipende".


Se non sai qual è la sua funzione o come si configura, probabilmente non ti serve.
Se non sai qual è la sua funzione o come si configura, probabilmente non ti serve.<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 desktop monoutente (il computer di casa, il portatile, il PC dell'ufficio), <code>sudo</code> è 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.
Su una macchina server, invece, il comando <code>sudo</code> è a volte necessario se non indispensabile.<br/>
Sudo permette all'amministratore del server di concedere privilegi di esecuzione per comandi ben precisi e solo ad utentu (o host) ben definiti.
Sudo permette all'amministratore del server di concedere privilegi di esecuzione per comandi ben precisi e solo ad utentu (o [[host]]) ben definiti.<br/>
Il tutto si traduce in una maggiore flessibilità nelle operazioni di gestione della macchina.
Il tutto si traduce in una maggiore flessibilità nelle operazioni di gestione della macchina.


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


== ERRORI COMUNI ==
=== Errori comuni ===
Un breve elenco di operazioni da evitare nell'uso e configurazione di sudo.
Un breve elenco di operazioni da evitare nell'uso e configurazione di <code>sudo</code>.
<!--
* SEZIONE COMMENTATA *
;'''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...


- ALL : ALL
;Aggiungere il proprio utente al gruppo <code>sudo</code>
Il primo errore consiste nell'inserire la riga:
:Altro errore è aggiungere il proprio utente al gruppo <code>sudo</code>:<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 <code>sudo</code> 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 <code>sudo</code>, 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.
utente ALL:ALL
-->
oppure la riga:
utente ALL = (ALL) ALL
In questo modo si dà il permesso a utente di fare qualunque cosa previo inserimento della propria password.
Ma perché ricorrere a tale soluzione quando si può essere ugualmente distruttivi con...


- Aggiungere il proprio utente al gruppo sudo
;Rimuovere l'autenticazione
Altro errore è aggiungere il proprio utente al gruppo sudo:
:La rimozione dell'autenticazione (vedere l'opzione "authenticate") è, di per sé, un'operazione generalmente da evitare in quanto, senza ulteriori configurazioni, elimina la richiesta di inserimento password per un utente che, attraverso <code>sudo</code>, esegue un comando (o più comandi). Inoltre è foriera di sicuri errori di configurazione quando il file <code>/etc/sudoers</code> contiene numerose linee.<br/>In congiunzione con uno dei due errori descritti in precedenza, però, questa operazione assume i caratteri del cataclisma: chiunque può eseguire comandi di sistema attraverso <code>sudo</code>, da qualunque parte del mondo si trovi e senza nessuna password da immettere. L'unica limitazione sarà l'accesso (fisico o remoto) al vostro host.
# adduser nome_utente sudo
ed effettuare un logout/login.


Poiché in /etc/sudoers esiste la riga:
;Modifiche frequenti ai file
%sudo ALL = (ALL):ALL
:Se modificate frequentemente i file di sistema, potrebbe sorgere l'illusoria esigenza di dover installare <code>sudo</code>.<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 <code>sudo</code>, 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).
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).
Si otterrà effettivamente il funzionamento di sudo, ma a che prezzo?
L'utente può eseguire qualunque comando semplicemente inserendo la propria password. Quindi:
1 cade la distinzione tra utente normale e amministratore
2 si permette a chiunque conosca la password, di eseguire tutti i comandi di sistema
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.
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.


-Modifiche frequenti ai file.
;Sudo semplifica l'amministrazione
Se modificate frequentemente i file di sistema, potrebbe sorgere l'illusoria esigenza di dover installare sudo.
:Sudo semplifica l'amministrazione del sistema solo se si sa esattamente quali sono le proprie esigenze e come si modifica correttamente il file <code>/etc/sudoers</code> .<br/>Se pensate che 'semplificare' coincida con il dimenticarsi della password di root (o, peggio ancora, con il non averla), siete fuori strada e, probabilmente, Debian non è la distribuzione che fa per voi.
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.
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).


- Sudo semplifica l'amministrazione
;Sudo e l'escape della shell
Sudo semplifica l'amministrazione del sistema solo se si sa esattamente quali sono le proprie esigenze e come si modifica correttamente il file etc/sudoers.  
:Un errore molto meno marchiano è utilizzare <code>sudo</code> 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 una shell (vedere [Vim Cheat Sheet|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 <code>sudoers</code> 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.
Se pensate che 'semplificare' coincida con il dimenticarsi della password di root (o, peggio ancora, con il non averla), siete fuori strada e, probabilmente, Debian on è la distribuzione che fa per voi.


-Sudo e l'escape della shell
;Modifica dei file
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.
:La precedente riga:<pre>pippo localhost = NOEXEC : /usr/bin/vim /etc/apt/sources.list</pre>effettivamente impedisce che Vim possa eseguire una shell. Il problema è che non impedisce che Vim possa aprire un altro file e modificarlo. Oppure creare un file in un punto qualunque del filesystem.<br/>La soluzione è utilizzare ''sudoedit'':<pre>pippo localhost = NOEXEC : sudoedit /etc/apt/sources.list</pre>
Consideriamo la seguente riga in /etc/sudoers:
pippo ALL = /usr/bin/vim /etc/apt/sources.list
in buona fede si potrebbe pensare di concedere all'utente pippo la sola modifica del file /etc/apt/sources.list attraverso Vim. Malauguratamente Vim, e altri programmi, permettono di eseguire un shell (vedere qui)
Per cui l'utente pippo, un volta eseguito il comando:
$ sudo vim /etc/apt/sources.list
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.
La soluzione è modificare il file sudoers così:
pippo localhost = NOEXEC : /usr/bin/vim /etc/apt/sources.list
o utilizzare altro editor (nano) che non permetta l'escape della shell.


- Modifica dei file
=== Consigli utili ===
La precedente riga:
* Non installare <code>sudo</code> su macchine desktop.<br/>Avvalersi, piuttosto, degli strumenti alternativi (grafici e testuali) che Debian mette a disposizione.
pippo localhost = NOEXEC : /usr/bin/vim /etc/apt/sources.list
effettivamente impedisce che Vim possa eseguire una shell. Il problema è che non impedisce che Vim possa aprire un altro file e modificarlo. Oppure creare un file in un punto qualunque del filesystem.
La soluzione è utilizzare sudoedit
pippo localhost = NOEXEC : /usr/bin/sudoedit /etc/apt/sources.list


== CONSIGLI UTILI ==
* Se si decide di utilizzare <code>sudo</code>, documentarsi sul suo funzionamento e la sua configurazione.<br/>Documentarsi anche sul funzionamento di ogni programma che si è deciso di avviare attraverso <code>sudo</code>.
- Non installare sudo su macchine desktop.
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.
* Utilizzare ''sudoedit'' anziché direttamente programmi che permettono l'escape della shell
Documentarsi anche sul funzionamento di ogni programma che si è deciso di avviare attraverso sudo.


- Utilizzare sudoedit anziché direttamente programmi che permettono l'escape della shell
* Utilizzare ''sudoedit'' ogni volta che si vuol editare un file.


- tenere sempre presente che la priorità è la sicurezza della Debian box.
* Tenere sempre presente che la priorità è la sicurezza della Debian box.<br/>In un mondo interconnesso, la compromissione della sicurezza della vostra macchina non è solo un problema per voi stessi ma anche un serio problema per ogni computer del globo.
In un mondo interconnesso, la compromissione della sicurezza della vostra macchina non è solo un problema per voi stessi ma anche un serio problema per ogni computer del globo.


- Valutare attentamente i vantaggi e gli svantaggi a cui si va incontro utilizzando sudo.
* Valutare attentamente i vantaggi e gli svantaggi a cui si va incontro utilizzando <code>sudo</code>.


== INSTALLAZIONE ==
== Installazione ==
Sudo, contrariamente a quanto si possa pensare, non è uno strumento essenziale per la configurazione del sistema e non viene installato di default in Debian. Per installarlo, è necessario impartire esplicitamente un:
Sudo, contrariamente a quanto si possa pensare, non è uno strumento essenziale per la configurazione del sistema e non viene installato di default in Debian. Per installarlo, è necessario impartire esplicitamente un:
<pre># apt-get install sudo</pre>
<pre># apt-get install sudo</pre>
Riga 107: Riga 81:
Se si vuole riavere una  password di root non vuota, basta eseguire:
Se si vuole riavere una  password di root non vuota, basta eseguire:
<pre>$ sudo passwd root</pre>
<pre>$ sudo passwd root</pre>
e poi rimuovere il proprio utente dal gruppo sudo:
e poi rimuovere il proprio utente dal gruppo <code>sudo</code>:
# deluser nome_utente sudo
<pre># deluser nome_utente sudo</pre>
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.
Questo disabilita <code>sudo</code> 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.
Se ci si dovesse chiedere del perché Debian non installi <code>sudo</code> 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.


== CONFIGURAZIONE ==
== Configurazione ==
La configurazione di sudo si ottiene con la modifica del file /etc/sudoers oppure con la creazione di file di configurazione nella directory /etc/sudoers.d/ .
La configurazione di <code>sudo</code> 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> .
/ETC/SUDOERS
 
Per modificare il file sudoers c'è un'unica strada, utilizzare da root il comando:
=== Il file <code>/etc/sudoers</code> ===
# visudo
Per modificare il file <code>sudoers</code> c'è un'unica strada, utilizzare da root il comando:
<pre># visudo</pre>
In questo modo viene eseguito l'editor di default, rigorosamente testuale.
In questo modo viene eseguito l'editor di default, rigorosamente testuale.


Il file all'inizio si presenta così:
Il file all'inizio si presenta così:
  #
  #
  # This file MUST be edited with the 'visudo' command as root.
  # This file MUST be edited with the 'visudo' command as root.
Riga 138: Riga 114:
   
   
  # Cmnd alias specification
  # Cmnd alias specification
 
  # User privilege specification
  # User privilege specification
  '''root    ALL=(ALL:ALL) ALL'''
  '''root    ALL=(ALL:ALL) ALL'''
 
  # Allow members of group sudo to execute any command
  # Allow members of group sudo to execute any command
  '''%sudo  ALL=(ALL:ALL) ALL'''
  '''%sudo  ALL=(ALL:ALL) ALL'''
 
  # See sudoers(5) for more information on "#include" directives:
  # See sudoers(5) for more information on "#include" directives:
   
   
  '''#includedir /etc/sudoers.d'''
  '''#includedir /etc/sudoers.d'''
 
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.
Le righe in grassetto sono quelle significative. I commenti (righe che iniziano con #) o le righe vuote non contribuiscono alla configurazione di <code>sudo</code> ma sono comunque importanti per la leggibilità del file.<br/>
L'ultima linea, in cui è contenuta la direttiva "#includedir", rappresenta un'eccezione alla regola precedente e non viene vista come un commento.
L'ultima linea, in cui è contenuta la direttiva "#includedir", rappresenta un'eccezione alla regola precedente e non viene vista come un commento.


Prestare attenzione al fatto che aggiornamenti del pacchetto sudo potrebbero chiedere di sovrascrivere questo file.
Prestare attenzione al fatto che aggiornamenti del pacchetto <code>sudo</code> potrebbero chiedere di sovrascrivere questo file.<br/>
Benché in fase di aggiornamento gli avvertimenti siano piuttosto chiari (verrà chiesto esplicitamente se mantenere il file, se sovrascriverlo, guardare i cambiamenti introdotti etc.), è consigliato creare una copia di backup e custodirla al sicuro.
Benché in fase di aggiornamento gli avvertimenti siano piuttosto chiari (verrà chiesto esplicitamente se mantenere il file, se sovrascriverlo, guardare i cambiamenti introdotti etc.), è consigliato creare una copia di backup e custodirla al sicuro.


/SUDOERS.D
=== La directory <code>/etc/sudoers.d/</code> ===
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.
In caso si debba scrivere un elevato numero di righe, si può far uso della directory <code>/etc/sudoers.d/</code> in cui è possibile creare tutti i file che si ritengono necessari per configurare <code>sudo</code>. Questi verranno visti in sequenza come un unico file di configurazione.
1 Il file sudoers viene comunque e sempre letto per primo
* Il file <code>sudoers</code> viene comunque e sempre letto per primo
2 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>
* Affinché questi file possano essere considerati come file di configurazione, è necessario che sia presente in <code>/etc/sudoers</code> la riga:<pre>#includedir /etc/sudoers.d</pre>
3 I file non possono contenere punti nel loro nome
* I file non possono contenere punti nel loro nome
4 I file che terminano con ~ non vengono considerati
* I file che terminano con ~ non vengono considerati
5 È opportuno dare i permessi 0440 a questi file:<pre># chmod 0440 /etc/sudoers.d/*</pre>in modo che siano leggibili e scrivibili solo da root
* È opportuno dare i permessi 0440 a questi file:<pre># chmod 0440 /etc/sudoers.d/*</pre>in modo che siano leggibili e scrivibili solo da root
6 I file sono letti in ordine alfabetico. Si consiglia di anteporre un numero al loro nome in modo da avere la certezza che i file vengano letti nell'ordine desiderato. Ad esempio: 00topolino, 01pippo, 02 pluto, .... , 99gambadilegno
* I file sono letti in ordine alfabetico. Si consiglia di anteporre un numero al loro nome in modo da avere la certezza che i file vengano letti nell'ordine desiderato. Ad esempio: 00topolino, 01pippo, 02 pluto, .... , 99gambadilegno
7 Scegliere nomi significativi (07alias_comandi_per_l_utente_pippo è preferibile a 07config).
* Scegliere nomi significativi ("07alias_comandi_per_l_utente_pippo" è preferibile a "07config").
8 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.
* 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 <code>sudoers</code>.
9 Suddividere i file in maniera logica (per utente, per host, per gruppi, per comandi, etc.) e commentare ogni aggiunta o modifica. Questo consentirà, sia a voi sia a chi si troverà a leggerli, di interpretarli con maggior semplicità e chiarezza
* Suddividere i file in maniera logica (per utente, per host, per gruppi, per comandi, etc.) e commentare ogni aggiunta o modifica. Questo consentirà, sia a voi sia a chi si troverà a leggerli, di interpretarli con maggior semplicità e chiarezza
10 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>
* A differenza del file <code>sudoers</code>, è possibile creare e modificare questi file con un editor grafico attraverso "gksu" o "kdesu"<pre>$ gksu gedit /etc/sudoers.d/01pippo</pre>
11 Tutti i file presenti in questa directory non saranno sovrascritti o cancellati da futuri aggiornamenti del pacchetto sudo
* Tutti i file presenti in questa directory non saranno sovrascritti o cancellati da futuri aggiornamenti del pacchetto <code>sudo</code>
 
Leggere anche il file <code>/etc/sudoers.d/README</code>
 
=== Struttura ===
Riprendiamo il file <code>/etc/sudoers</code> per analizzarne la struttura. Possiamo vedere che esistono quattro sezioni.


Leggere anche:
'''Opzioni di default'''<br/>
<pre># cat /etc/sudoers.d/README</pre>
<pre>
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
</pre>


STRUTTURA
'''Alias'''<br/>
Riprendiamo il file /etc/sudoers per analizzarne la struttura. Possiamo vedere che esistono quattro sezioni:
<pre>
- Opzioni di default
# Host alias specification
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
- Alias
# Host alias specification
   
   
# User alias specification
# User alias specification
   
   
# Cmnd alias specification
# Cmnd alias specification
inizialmente vuoto
</pre>
- Specifiche
inizialmente vuoto.
root    ALL=(ALL:ALL) ALL
%sudo  ALL=(ALL:ALL) ALL


- Direttiva #includedir (TODO #include)
'''Specifiche'''<br/>
  #includedir /etc/sudoers.d
<pre>
root    ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL
</pre>


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.
'''Direttiva #includedir <!--(TODO #include)-->'''<br/>
<pre>#includedir /etc/sudoers.d</pre>
Quest'ultima sezione indica la directory in cui leggere eventuali e ulteriori file di configurazione di <code>sudo</code>. Andrebbe lasciata in fondo al file ed, eventualmente, modificata specificando altra directory se si hanno esigenze particolari.
   
   
Le prime tre sezioni verranno analizzate separatamente ed è raccomandato mantenerle separate e nell'ordine indicato. Benché sia possibile mescolare gli alias con le specifiche e con le opzioni di default, il risultato sarebbe solo quello di rendere illeggibile il file di configurazione e, spesso, sperimentare comportamenti indesiderati.
Le prime tre sezioni verranno analizzate separatamente ed è raccomandato mantenerle separate e nell'ordine indicato. Benché sia possibile mescolare gli alias con le specifiche e con le opzioni di default, il risultato sarebbe solo quello di rendere illeggibile il file di configurazione e, spesso, sperimentare comportamenti indesiderati.
 
== Specifiche ==
Eccoci giunti al cuore del file <code>sudoers</code>: le righe che indicano in che modo e con quali comandi è possibile invocare <code>sudo</code>.<br/>
Una riga è costituita da diversi parametri strutturati in questo modo:
<pre>CHI HOST=(ALTRO_UTENTE:ALTRO_GRUPPO) EVENTUALI_TAG:COMANDO</pre>
I parametri obbligatori sono:
* '''CHI''', cioè il nome dell'utente linux cui è consentito eseguire <code>sudo</code>
* '''HOST''', cioè il ''luogo'' da cui è permesso eseguire <code>sudo</code>
* Il carattere <code>=</code>
* '''COMANDO''', cioè il comando che ''CHI'' può eseguire, avendo cura di specificarlo dandone il percorso (''path'') assoluto (''/path/to/command'').
I parametri facoltativi sono:
* '''ALTRO_UTENTE''' e '''ALTRO_GRUPPO''' permettono di specificare con che nome utente e gruppo il comando dovrà essere eseguito. Omettere questi due parametri significa dire implicitamente al sistema che il comando deve essere eseguito con i privilegi di '''root''' (il comportamento desiderato nella maggior parte dei casi). Se però si decide di specificarli è necessario specificare entrambi i parametri come sopra indicato, ovvero racchiudendoli tra parentesi e separandoli col carattere <code>:</code>..
* '''EVENTUALI_TAG'''. Devono essere inseriti prima del comando a cui si applicano e separati da questo da un carattere <code>:</code>
Di seguito un semplice esempio del tutto teorico:
<pre>pippo topolinia = (topolino:topolino) NOPASSWD:/path/assoluto/del/comando</pre>
Questa riga indica che l'utente pippo (CHI) potrà eseguire il comando solo dall'host "topolinia" e con le credenziali dell'utente topolino (ALTRO_UTENTE) e del gruppo topolino (ALTRO_GRUPPO) senza richiedere la password di pippo prima di eseguire il comando (NOPASSWD è proprio uno degli EVENTUALI_TAG che è possibile dichiarare).
 
=== Chi ===
La prima parola indica chi può eseguire <code>sudo</code>. Questa può essere uno username, un gruppo (preceduto da %), un netgroup (preceduto da "+") o un alias di tipo User_Alias.<br/>
Quindi se:
<pre>
User_Alias DISNEY = cenerentola, biancaneve
 
pippo ALL = comando
%topolia ALL = comando2
+paperopoli ALL = comando3
DISNEY ALL = comando4
</pre>
L'utente pippo può eseguire il comando:
<pre>$ sudo comando</pre>
L'utente topolino può eseguire:
<pre>sudo comando2</pre>
ma solo se fa parte del gruppo "topolinia".<br/>
L'utente paperino può eseguire:
<pre>$ sudo comando3</pre>
ma solo se fa parte del gruppo di rete "paperopoli".<br/>
Biancaneve e cenerentola possono eseguire:
<pre>$ sudo comando4</pre>
 
Di default a tutti viene chiesta la propria password. Nel caso l'utente non sia abilitato ad eseguire un comando con <code>sudo</code>:
<pre>Sorry, user nomeutente is not allowed to execute comando as root on nomehost.</pre>
Come si vede chiaramente, di default <code>sudo</code> cerca di eseguire il comando con i permessi di root (che è poi il compito per cui viene utilizzato).
 
Un esempio funzionante è il seguente:
<pre>pippo ALL = /usr/bin/ifconfig -a</pre>
con cui pippo può eseguire un comando che richiede i permessi di root:
<pre>$ sudo ifconfig -a</pre>
questo visualizzerà le interfacce di rete previo inserimento da parte di pippo della propria password.
 
=== Da dove ===
La seconda parola specifica il nome dell'host da cui è permesso eseguire <code>sudo</code>. Possono essere specificati anche indirizzi IP o indirizzi di rete con submask.<br/>
La parola "ALL" indica che gli utenti potranno eseguire <code>sudo</code> da qualsiasi host.<br/>
Lo scopo di questa voce è chiaro, magari si vuol consentire a pippo di eseguire <code>sudo</code> solo da una macchina della rete locale:
<pre>pippo 192.168.1.80 = comando</pre>
A questo proposito è sempre opportuno specificare l'IP o l'host e non utilizzare la parola "ALL". Il nome dell'host si può ricavare con il comando:
<pre>$ hostname</pre>
Ad esempio:
<pre>$ hostname
pippohost</pre>
e la configurazione sarà:
<pre>pippo pippohost = comando</pre>
 
=== Tag ===
I [[tag]] utilizzati da <code>sudo</code> precedono immediatamente il [[path]] assoluto del comando e sono separati da questo da un carattere di ":". Ad esempio:
utente host = '''TAG''':comando
Sono permessi più tag, in questo caso è necessario separarli con un carattere ":", ad esempio:
utente host = '''TAG1:TAG2''':comando
I tag consentiti sono dieci:
*PASSWD e NOPASSWD
*EXEC e NOEXEC
*SETENV e NOSETENV
*LOG_INPUT e NOLOG_INPUT
*LOG_OUTPUT e NOLOG_OUTPUT
Questi tag, come si può notare, compongono delle coppie duali in cui un tag della coppia può sovrascrivere una precedente impostazione creata dall'altro componente della coppia.
 
Dovrebbe essere facilmente intuibile l'assoluta inutilità, benché sia consentito farlo, di specificare tag duali sulla stessa riga. Ad esempio:
utente host = PASSWD:NOPASSWD:comando
Questa notazione è assolutamente identica a:
utente host = NOPASSWD:comando
in quanto il tag che crea l'impostazione sovrascrive l'impostazione creata dal tag duale. In questo caso, quindi, avrà effetto solo l'impostazione creata dal tag della coppia che viene scritto per ultimo.
   
   
ALIAS
<!--(TODO: permessi utente/gruppo comando)-->
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.
 
Come lascia intuire il nome, gli alias permettono di raggruppare logicamente il nome di un certo numero di utenti, di host, di gruppi o di comandi, in modo da farvi riferimento in modo semplice e veloce attraverso una sola stringa identificativa (il nome dell'alias).
== Alias ==
Facciamo un esempio chiarificatore anche se non realistico.
Iniziamo ad analizzare gli alias, inizialmente non specificati. Questo indica che, in sostanza, non sono strettamente necessari per configurare <code>sudo</code>, 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.
 
Come lascia intuire il nome, gli alias permettono di raggruppare logicamente il nome di un certo numero di utenti, di host, di gruppi o di comandi, in modo da farvi riferimento in modo semplice e veloce attraverso una sola stringa identificativa (il nome dell'alias).<br/>
Facciamo un esempio non realistico.<br/>
Supponiamo di avere una configurazione che contiene:
Supponiamo di avere una configurazione che contiene:
<pre>
<pre>
Riga 206: Riga 272:
pippo ALL = /usr/bin/rm /media/share/temp/*
pippo ALL = /usr/bin/rm /media/share/temp/*
</pre>
</pre>
con cui l'utente pippo ha il permesso di cancellare determinati file. Che accade se l'amministratore di sistema decide di concedere gli stessi permessi all'utente pluto? O se decide di togliere i permessi a pippo e di darli a pluto? O se vuole modificare il comando "rm" passandogli un'opzione? Con questa configurazione dovrà modificare una per una tutte le linee (nell'esempio sono tre, ma potrebbero essere molte di più).
con cui l'utente pippo ha il permesso di cancellare determinati file. Che accade se l'amministratore di sistema decide di concedere gli stessi permessi all'utente pluto? O se decide di togliere i permessi a pippo e di darli a pluto? O se vuole modificare il comando "rm" passandogli un'opzione? Con questa configurazione dovrà modificare una per una tutte le linee (nell'esempio sono tre, ma potrebbero essere molte di più).<br/>
La soluzione è ricorrere agli alias:
La soluzione è ricorrere agli alias:
<pre>
User_Alias UTENTI_RM = pippo
User_Alias UTENTI_RM = pippo
Cmnd_Alias COMANDO_RM = "/usr/bin/rm"
Cmnd_Alias COMANDO_RM = "/usr/bin/rm"
Riga 214: Riga 281:
UTENTI_RM ALL = COMANDO_RM /log/app/*
UTENTI_RM ALL = COMANDO_RM /log/app/*
UTENTI_RM ALL = COMANDO_RM /media/share/temp/*
UTENTI_RM ALL = COMANDO_RM /media/share/temp/*
</pre>


A questo punto, se si vogliono concedere gli stessi permessi a pluto:
A questo punto, se si vogliono concedere gli stessi permessi a pluto:
<pre>
User_Alias UTENTI_RM = pippo, pluto
User_Alias UTENTI_RM = pippo, pluto
Cmnd_Alias COMANDO_RM = "/usr/bin/rm"
Cmnd_Alias COMANDO_RM = "/usr/bin/rm"
Riga 222: Riga 291:
UTENTI_RM ALL = COMANDO_RM /log/app/*
UTENTI_RM ALL = COMANDO_RM /log/app/*
UTENTI_RM ALL = COMANDO_RM /media/share/temp/*
UTENTI_RM ALL = COMANDO_RM /media/share/temp/*
 
</pre>
Se si vuol cambiare anche il comando:
Se si vuol cambiare anche il comando:
<pre>
User_Alias UTENTI_RM = pippo, pluto
User_Alias UTENTI_RM = pippo, pluto
Cmnd_Alias COMANDO_RM = "/usr/bin/rm -rf"
Cmnd_Alias COMANDO_RM = "/usr/bin/rm -rf"
Riga 230: Riga 300:
UTENTI_RM ALL = COMANDO_RM /log/app/*
UTENTI_RM ALL = COMANDO_RM /log/app/*
UTENTI_RM ALL = COMANDO_RM /media/share/temp/*
UTENTI_RM ALL = COMANDO_RM /media/share/temp/*
 
</pre>
si può notare che la modifica avviene in un solo punto del file con le ultime tre righe che restano invariate.
si può notare che la modifica avviene in un solo punto del file con le ultime tre righe che restano invariate.


SINTASSI
=== Sintassi degli alias ===
La sintassi è:
La sintassi è:
<pre>Tipo_di_alias NOME_ALIAS = Lista</pre>
<pre>Tipo_di_alias NOME_ALIAS = Lista</pre>
   
   
-Tipo_di_alias
;Tipo_di_alias:Ciacuna riga che identifica un alias deve iniziare necessariamente con una parola che stabilisce il tipo di alias che stiamo creando. Questa parole sono quattro:<br/>- User_Alias<br/>- Runas_Alias<br/>- Host_Alias<br/>- Cmnd_Alias<br/>e vanno scritte esattamente in questa forma.
Ciacuna riga che identifica un alias deve iniziare necessariamente con una parola che stabilisce il tipo di alias che stiamo creando. Questa parole sono quattro:
- User_Alias
- Runas_Alias
- Host_Alias
- Cmnd_Alias
e vanno scritte esattamente in questa forma.
   
   
-Nome alias
;Nome alias:Questa è la stringa a cui potrà farà riferimento in altri alias o nelle specifiche.<br/>- Deve essere composto da lettere maiuscole, lettere minuscole o caratteri di underscore "_" . Altri caratteri non sono ammessi.<br/>- Deve necessariamente iniziare con una lettera maiuscola<br/>- Per maggiore chiarezza è una buona idea scriverlo in sole lettere maiuscole
Questa è la stringa a cui potrà farà riferimento in altri alias o nelle specifiche.
1 - Deve essere composto da lettere maiuscole, lettere minuscole o caratteri di underscore "_" . Altri caratteri non sono ammessi.
2 - Deve necessariamente iniziare con una lettera maiuscola
3 - Per maggiore chiarezza è una buona idea scriverlo in sole lettere maiuscole
 
- Lista
A differenza del tipo e del nome dell'alias, la scrittura di una lista è leggermente più articolata e dipende dal tipo di alias specificato. Gli elementi che compongono una lista devono essere separati da una virgola e vanno quotati tra doppie virgolette se contengono caratteri speciali; la lista può contenere anche altri alias purché questi siano già stati definiti. Ad esempio:
User_Alias UTENTI1 = pippo, pluto
User_Alias UTENTI2 = paperino, gastone, UTENTI1
 
UTENTI2 ALL = /usr/bin/tail /var/log/syslog


e gli utenti pippo e pluto possono visualizzare le ultime righe del file /var/log/syslog
;Lista:A differenza del tipo e del nome dell'alias, la scrittura di una lista è leggermente più articolata e dipende dal tipo di alias specificato. Gli elementi che compongono una lista devono essere separati da una virgola e vanno quotati tra doppie virgolette se contengono caratteri speciali; la lista può contenere anche altri alias purché questi siano già stati definiti. Ad esempio:<pre>User_Alias UTENTI1 = pippo, pluto&#10;User_Alias UTENTI2 = paperino, gastone, UTENTI1&#10;&#10;UTENTI2 ALL = /usr/bin/tail /var/log/syslog</pre>
e gli utenti pippo e pluto possono visualizzare le ultime righe del file <code>/var/log/syslog</code> .


-- Alias di tipo User_Alias
==== Alias di tipo User_Alias ====
Una lista di questo tipo è composta da uno o più nomi utente, UID, gruppi, gruppi di rete, gruppi di tipo "nonunix" o altri alias di tipo User_Alias.
Una lista di questo tipo è composta da uno o più nomi utente, UID, gruppi, gruppi di rete, gruppi di tipo "nonunix" o altri alias di tipo User_Alias.<br/>
I nomi utente (username) vanno scritti "as is", seguendo la distinzione maiuscole/minuscole (Pippo e pippo sono utenti diversi)
I nomi utente (username) vanno scritti "as is", seguendo la distinzione maiuscole/minuscole (Pippo e pippo sono utenti diversi).<br/>
Gli UID identificano un utente e vanno preceduti da un carattere cancelletto "#" (ad es. #1000, #1001, #1002)
Gli UID identificano un utente e vanno preceduti da un carattere cancelletto "#" (ad es. #1000, #1001, #1002).<br/>
I gruppi sono preceduti dal carattere di percentuale (%) e sono quelli letti nel file /etc/group (ad es. %adm, %src, %plugdev)
I gruppi sono preceduti dal carattere di percentuale (%) e sono quelli letti nel file /etc/group (ad es. %adm, %src, %plugdev).<br/>
Gli alias di tipo User_Alias vanno scritti con il loro nome e devono essere stati definiti in precedenza.
Gli alias di tipo User_Alias vanno scritti con il loro nome e devono essere stati definiti in precedenza.


Esempio 1
'''Esempio 1'''
<pre>
User_Alias PAPEROPOLI = paperoga, paperina, gastone
User_Alias PAPEROPOLI = paperoga, paperina, gastone
PAPEROPOLI ALL = /usr/bin/ifconfig -a > ifconfig.txt
PAPEROPOLI ALL = /usr/bin/ifconfig -a > ifconfig.txt
</pre>
gli utenti paperoga, paperina e gastone possono creare un file nella directory corrente con l'output del comando "ifconfig -a' .
gli utenti paperoga, paperina e gastone possono creare un file nella directory corrente con l'output del comando "ifconfig -a' .


Esempio 2
'''Esempio 2'''
<pre>
User_Alias FANTASY = %robot, !goldrake, godzilla
User_Alias FANTASY = %robot, !goldrake, godzilla
FANTASY ALL = /bin/rm /tmp/tempdir/*
FANTASY ALL = /bin/rm /tmp/tempdir/*
</pre>
tutti i file della directory "/tmp/tempdir" possono essere cancellati solo dagli utenti che fanno parte del gruppo "robot", dall'utente godzilla (anche se non fa parte del gruppo "robot") ma non dall'utente goldrake (anche se fa parte del gruppo "robot")
tutti i file della directory "/tmp/tempdir" possono essere cancellati solo dagli utenti che fanno parte del gruppo "robot", dall'utente godzilla (anche se non fa parte del gruppo "robot") ma non dall'utente goldrake (anche se fa parte del gruppo "robot")


Esempio 3
'''Esempio 3'''
<pre>
User_Alias TOPOLINIA = topolino, #1005, %bandabassotti, minnie, !371-173
User_Alias TOPOLINIA = topolino, #1005, %bandabassotti, minnie, !371-173
TOPOLINIA ALL = /myscripts/backup.sh
TOPOLINIA ALL = /myscripts/backup.sh
gli utenti topolino e minnie, gli utenti che fanno parte del gruppo "bandabassotti" e l'utente con UID uguale a 1005 possono eseguire uno script di backup.
</pre>
gli utenti topolino e minnie, gli utenti che fanno parte del gruppo "bandabassotti" e l'utente con UID uguale a 1005 possono eseguire uno script di backup.<br/>
Non può eseguire lo script l'utente 371-173 anche se fa parte del gruppo "bandabassotti".
Non può eseguire lo script l'utente 371-173 anche se fa parte del gruppo "bandabassotti".


Esempio 4  
'''Esempio 4'''
<pre>
User_Alias PAPEROPOLI = paperoga, paperina
User_Alias PAPEROPOLI = paperoga, paperina
User_Alias NIPOTI_DI_PAPERINO = qui, quo, qua
User_Alias NIPOTI_DI_PAPERINO = qui, quo, qua
User_Alias DISNEY = %biancaneve, #1001, PAPEROPOLI, NIPOTI_DI_PAPERINO, !paperoga, !quo
User_Alias DISNEY = %biancaneve, #1001, PAPEROPOLI, NIPOTI_DI_PAPERINO, !paperoga, !quo


DISNEY ALL = NOEXEC:/usr/bin/vim /etc/apt/sources.list  
DISNEY ALL = NOEXEC:/usr/bin/vim /etc/apt/sources.list
il file /etc/apt/sources.list può essere modificato solo dall'utente con UID uguale a 1001, dagli utenti del gruppo biancaneve, da qui e da qua. Non può essere modificato da paperoga e quo.
</pre>
il file <code>/etc/apt/sources.list</code> può essere modificato solo dall'utente con UID uguale a 1001, da paperina, dagli utenti del gruppo biancaneve, da qui e da qua. Non può essere modificato da paperoga e quo.


-- Alias di tipo Host_Alias
==== Alias di tipo Host_Alias ====
In questa lista possono essere compresi nomi di host, indirizzi IP, indirizzi di rete con relativa submask (sia in formato standard che con la notazione CIDR), gruppi di rete (preceduti dal carattere "+") o altri alias di tipi Host_Alias.
In questa lista possono essere compresi nomi di host, indirizzi IP, indirizzi di rete con relativa submask (sia in formato standard che con la notazione CIDR), gruppi di rete (preceduti dal carattere "+") o altri alias di tipi Host_Alias.<br/>
Il carattere "!" nega un elemento della lista come nel caso precedente.
Il carattere "!" nega un elemento della lista come nel caso precedente.
Esempio
 
Ad esempio:
<pre>Host_Alias TRUSTED = server1, 192.168.1.23, 10.0.0.0/24, +grupporete</pre>
<pre>Host_Alias TRUSTED = server1, 192.168.1.23, 10.0.0.0/24, +grupporete</pre>


-- Alias di tipo Cmd_Alias
==== Alias di tipo Cmnd_Alias ====
Lista che contiene uno o più comandi o directory.
Lista che contiene uno o più comandi o directory.
1) I comandi devono essere scritti esattamente insieme al loro path assoluto (whereis nomecomando per trovarlo)
* I comandi devono essere scritti esattamente insieme al loro path assoluto ("whereis nomecomando" per trovarlo)
2) I comandi funzionano anche se vengono eseguiti insieme a dei parametri, per cui se:
* I comandi funzionano anche se vengono eseguiti insieme a dei parametri, per cui se:
Cmd_Alias LS = /bin/ls
<pre>
Cmnd_Alias LS = /bin/ls
pippo ALL = LS
pippo ALL = LS
 
</pre>
il seguente comando non produrrà un errore:
il seguente comando non produrrà un errore:
<pre>$ sudo ls -l</pre>
<pre>$ sudo ls -l</pre>
Per evitare questo comportamento e consentire che il comando venga eseguito solo senza parametri, bisogna far seguire "" al comando:
Per evitare questo comportamento e consentire che il comando venga eseguito solo senza parametri, bisogna far seguire "" al comando:
<pre> Cmd_Alias LS = /bin/ls ""</pre>
<pre> Cmnd_Alias LS = /bin/ls ""</pre>
in questo modo sarà consentito solo:
in questo modo sarà consentito solo:
<pre>$ sudo ls</pre>
<pre>$ sudo ls</pre>
Riga 314: Riga 377:
<pre>$ sudo ls -l</pre>
<pre>$ sudo ls -l</pre>
Se si vogliono consentire solo determinati parametri, bisogna ricorrere ai metacaratteri. Ad esempio, per consentire i comandi "ls -l" e "ls -a" ma non "ls -d":
Se si vogliono consentire solo determinati parametri, bisogna ricorrere ai metacaratteri. Ad esempio, per consentire i comandi "ls -l" e "ls -a" ma non "ls -d":
<pre>Cmd_Alias LS = /bin/ls -[la]
<pre>Cmnd_Alias LS = /bin/ls -[la]
pippo ALL = LS</pre>
pippo ALL = LS</pre>
3) È 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 inserire anche il percorso assoluto di una directory, questo indicherà che potranno essere eseguiti con <code>sudo</code> tutti i programmi contenuti in quella directory ma non nelle sottodirectory. Ad esempio con:
<pre>Cmnd_Alias BIN = /bin/
<pre>Cmnd_Alias BIN = /bin/
pippo ALL = BIN</pre>
pippo ALL = BIN</pre>
è possibile eseguire con sudo tutto ciò che si trova in /bin/
è possibile eseguire con <code>sudo</code> tutto ciò che si trova in <code>/bin/</code>. Ad esempio il comando "cat":
<pre>$ sudo cat /var/log/kern.log</pre>
<pre>$ sudo cat /var/log/kern.log</pre>


-- Alias di tipo Runas_Alias
==== Alias di tipo Runas_Alias ====
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.
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 <code>sudo</code>.
Ad esempio:
Ad esempio:
<Runas_Alias AMICI = pippo, pluto, %adm
<pre>
paperino ALL = (AMICI) /usr/local/bin/script.sh</pre>
Runas_Alias AMICI = pippo, pluto, %adm
paperino ALL = (AMICI) /usr/local/bin/script.sh
</pre>
E paperino potrà eseguire:
E paperino potrà eseguire:
<pre>
<pre>
Riga 334: Riga 399:
ma anche:
ma anche:
<pre>$ sudo -u topolino /usr/local/bin/script.sh</pre>
<pre>$ sudo -u topolino /usr/local/bin/script.sh</pre>
se l'utente topolino fa parte del gruppo adm.
se l'utente topolino fa parte del gruppo <code>adm</code>.<br/>
Ovviamente tutti gli utenti coinvolti devono avere il permesso di eseguire lo script.
Ovviamente tutti gli utenti coinvolti devono avere il permesso di eseguire lo script.


SPECIFICHE
== Opzioni ==
Eccoci giunti al cuore del file sudoers: le righe che indicano in che modo e con quali comandi è possibile invocare sudo.
'''lecture'''<br/>
Una riga è costituita da diverse parti strutturate in questo modo:
Visualizza un avvertimento prima che un utente esegua un comando attraverso <code>sudo</code>. I possibili valori sono:<br/>
<pre>Chi_può_eseguire_sudo Da_quale_host = (Con_i_permessi_di_quale_utente : Con_i_permessi_di_quale_gruppo) EVENTUALI_TAG:Path_assoluto_del_comando_da eseguire</pre>
- always: l'avvertimento viene sempre visualizzato<br/>
Quindi:
- never: l'avvertimento non viene mai visualizzato<br/>
<pre>pippo topolinia = (topolino:topolino) NOPASSWD:/path/assoluto/del/comando
- once: l'avvertimento viene visualizzato solo la prima volta che un utente esegue <code>sudo</code>
significa che l'utente pippo potrà eseguire il comando solo dall'host "topolinia" e con le credenziali dell'utente topolino e del gruppo topolino. Non verrà chiesta la password.
Le uniche parti obbligatorie sono:
- L'utente a cui è consentito eseguire sudo
- L'host da cui si esegue sudo
- Il carattere "="
- Il path assoluto del comando da eseguire
Le voci facoltative sono:
- Credenziali utente e gruppo. Vanno inserite necessariamente tra parentesi.
- Eventuali tag. Vanno inseriti prima del comando a cui si applicano e separati da questo da un carattere ":"
 
CHI
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.
Quindi se:
<pre>
User_Alias DISNEY = cenerentola, biancaneve
 
pippo ALL = comando
%topolia ALL = comando2
+paperopoli ALL = comando3
DISNEY ALL = comando4
</pre>
L'utente pippo può eseguire il comando:
<pre>$ sudo comando</pre>
L'utente topolino può eseguire comando2 ma solo se fa parte del gruppo "topolinia":
<pre>sudo comando2</pre>
L'utente paperino può eseguire sudo con comando3 ma solo se fa parte del gruppo di rete "paperopoli":
<pre>$ sudo comando3</pre>
Biancaneve e cenerentola possono eseguire comando4
<pre>$ sudo comando4</pre>
di default  a tutti viene chiesta la propria password. Nel caso l'utente non sia abilitato ad eseguire un comando con sudo:
<pre>Sorry, user nomeutente is not allowed to execute comando as root on nomehost.</pre>
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).
Un esempio funzionante è il seguente:
<pre>pippo ALL = /usr/bin/ifconfig -a</pre>
con cui pippo può eseguire un comando che richiede i permessi di root:
<pre>$ sudo ifconfig -a</pre>
questo visualizzerà le interfacce di rete previo inserimento da parte di pippo della propria password.
 
DA DOVE
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 ...
La parola "ALL" indica che gli utenti potranno eseguire sudo da qualsiasi host.
Lo scopo di questa voce è chiaro, magari si vuol consentire a pippo di eseguire sudo solo da una macchina della rete locale:
<pre>pippo 192.168.1.80 = comando</pre>
A questo proposito è sempre opportuno specificare l'IP o l'host e non utilizzare la parola "ALL". Il nome dell'host si può ricavare con il comando:
<pre>$ hostname</pre>
Ad esempio:
<pre>$ hostname
pippohost</pre>
e la configurazione sarà:
<pre>pippo pippohost = comando</pre>
 
 
OPZIONI
 
lecture
Visualizza un avvertimento prima che un utente esegua un comando attraverso sudo. I possibili valori sono:
always = l'avvertimento viene sempre visualizzato
never = l'avvertimento non viene mai visualizzato
once = l'avvertimento viene visualizzato solo la prima vota che un utente esegue sudo


Di default l'avvertimento è:
Di default l'avvertimento è:
Riga 414: Riga 420:
Ad esempio:
Ad esempio:
<pre>Defaults lecture=always</pre>
<pre>Defaults lecture=always</pre>
stampa sempre un avvertimento.
stampa sempre un avvertimento.<br/>
Queste due righe sono equivalenti:
Queste due righe sono equivalenti:
<pre>
<pre>
Riga 421: Riga 427:
</pre>
</pre>


lecture_file
'''lecture_file'''<br/>
L'avvertimento di default può essere cambiato con questa opzione. Ad esempio, se l'avvertimento è contenuto nel file /etc/sudo_lecturefile :
L'avvertimento di default può essere cambiato con questa opzione. Ad esempio, se l'avvertimento è contenuto nel file <code>/etc/sudo_lecturefile</code> :
<pre>Defaults lecture=always
<pre>Defaults lecture=always
Defaults lecture_file="/etc/sudo_lecturefile"
Defaults lecture_file="/etc/sudo_lecturefile"
</pre>
</pre>


-passprompt (TODO: andata a capo)
'''passprompt<!--(TODO: andata a capo)-->'''<br/>
Permette di definire il prompt che verrà visualizzato alla richiesta password. Di default questo valore è impostato a:
Permette di definire il prompt che verrà visualizzato alla richiesta password. Di default questo valore è impostato a:
<pre>[sudo] password for %p: </pre>
<pre>[sudo] password for %p: </pre>
È possibile ricorrere a qualche carattere speciale
È possibile ricorrere a qualche carattere speciale<br/>
-%H : il nome dell'host (FQDN)
-%H : il nome dell'host (FQDN)<br/>
-%h : host non FQDN
-%h : host non FQDN<br/>
-%p : l'utente la cui password viene richiesta (%p può essere diverso dall'utente che esegue sudo)
-%p : l'utente la cui password viene richiesta (%p può essere diverso dall'utente che esegue <code>sudo</code>)<br/>
-%U : l'utente con i cui permessi verrà eseguito il comando (di default è root)
-%U : l'utente con i cui permessi verrà eseguito il comando (di default è root)<br/>
-%u : l'utente che esegue il comando attraverso sudo
-%u : l'utente che esegue il comando attraverso <code>sudo</code><br/>
Ad esempio:
Ad esempio:
<pre>Defaults passprompt="%u sta utilizzando sudo su %H. Il comando verrà eseguito con i permessi di %U. Inserisci la password di %p"
<pre>Defaults passprompt="%u sta utilizzando <code>sudo</code> su %H. Il comando verrà eseguito con i permessi di %U. Inserisci la password di %p"</pre>


LOG
LOG<br/>
-logfile
'''logfile'''<br/>
Il file di log per sudo, di default viene utilizzato /var/log/syslog . È 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.
Per il file di log per <code>sudo</code>, 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 <code>sudo</code>) 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/>
Creare il file di log:
Creare il file di log:
<pre># touch /var/log/sudo.log</pre>
<pre># touch /var/log/sudo.log</pre>
e poi, in /etc/sudoers :
e poi, in <code>/etc/sudoers</code> :
<pre>Defaults logfile="/var/log/sudo.log"
<pre>Defaults logfile="/var/log/sudo.log"</pre>


-log_host
'''log_host'''<br/>
Nel file di log (diverso da syslog) viene specificato l'host. Di default questa opzione è disabilitata, per abilitarla:
Nel file di log (diverso da <code>syslog</code>) viene specificato l'host. Di default questa opzione è disabilitata, per abilitarla:
<pre>Defaults log_host</pre>
<pre>Defaults log_host</pre>


-log_year
'''log_year'''<br/>
Nel file di log (diverso da syslog) viene specificato l'anno. Di default questa opzione è disabilitata, per abilitarla:
Nel file di log (diverso da <code>syslog</code>) viene specificato l'anno. Di default questa opzione è disabilitata, per abilitarla:
<pre>Defaults log_year</pre>
<pre>Defaults log_year</pre>


-loglinelen
'''loglinelen'''<br/>
Lunghezza delle linee del file di log. La lunghezza di default è 80 caratteri, superata la quale la linea viene tagliata sulla riga successiva. Per disabilitare questo comportamento:
Lunghezza delle linee del file di log. La lunghezza di default è 80 caratteri, superata la quale la linea viene tagliata sulla riga successiva. Per disabilitare questo comportamento:
<pre>
<pre>
Riga 465: Riga 471:
<pre>Defaults loglinelen=120</pre>
<pre>Defaults loglinelen=120</pre>


-log_input
'''log_input'''<br/>
Tutti gli input dell'utente attraverso una sessione sudo verranno loggati nella directory /var/log/sudo-io/. Ciascun file di questa directory ha un nome univoco in base al TSID (Terminal Session ID).
Tutti gli input dell'utente attraverso una sessione <code>sudo</code> 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:
Questa opzione è disabilitata di default. Per abilitarla:
<pre>Defaults log_input</pre>
<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 /var/log/sudo-io/nn/nn/nn/ttyin in formato compresso (nn sono stringhe di numeri-cifre), ad esempio per leggere l'input della sessione con TSID=000001:
TUTTI gli input degli utenti saranno loggati in chiaro, anche le password eventualmente digitate durante una sessione <code>sudo</code>. 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:
<pre># zless /var/log/sudo-io/00/00/01/ttyin</pre>
<pre># zless /var/log/sudo-io/00/00/01/ttyin</pre>


-log_output (TODO:CAMBIARE LA DATA)
'''log_output<!--(TODO:CAMBIARE LA DATA)-->'''<br/>
Tutti i messaggi visualizzati a schermo in una sessione sudo saranno loggati nella directory /var/log/sudo-io/, anche questi in base al TSID.
Tutti i messaggi visualizzati a schermo in una sessione <code>sudo</code> saranno loggati nella directory <code>/var/log/sudo-io/</code>, anche questi in base al TSID.<br/>
Questa opzione è disabilita di default. Per abilitarla:
Questa opzione è disabilitata di default. Per abilitarla:
<pre>Defaults log_output</pre>
<pre>Defaults log_output</pre>
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 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 <code>sudo</code>.
Ad esempio, se si vuol vedere ciò che ha visto l'utente pippo (e quindi anche ciò che ha digitato se è stato stampato a schermo) durante la sessione TSID=nnnnnn, si può innanzitutto trovare il TSID (supponiamo che sia 000003):
Ad esempio, se si vuol vedere ciò che ha visto l'utente pippo (e quindi anche ciò che ha digitato se è stato stampato a schermo) durante la sessione TSID=nnnnnn, si può innanzitutto trovare il TSID (supponiamo che sia 000003):
<pre>
<pre>
Riga 488: Riga 494:
vedere:
vedere:
<pre>man sudoreplay</pre>
<pre>man sudoreplay</pre>
per ottenere maggiori informazioni sul funzionamento di sudoreplay.
per ottenere maggiori informazioni sul funzionamento di <code>sudoreplay</code>.


{{Box|Nota|Nel caso abbiate la possibilità di utilizzare <code>sudo</code> su una macchina diversa dalla vostra, informatevi sulle politiche adottate dall'amministratore della macchina remota in merito alla gestione dei log di <code>sudo</code>. In ogni caso prestate attenzione all'inserimento, in sessioni <code>sudo</code>, di password o di qualunque altra informazione sensibile.}}


PASSWORD
PASSWORD<br/>
-authenticate
'''authenticate'''<br/>
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.
L'utente deve inserire una password per poter utilizzare <code>sudo</code> (di default: la propria password). Questo comportamento può essere bypassato attraverso i tag PASSWD e NOPASSWD.<br/>
Di default questa opzione è attiva. Per disabilitarla:
Di default questa opzione è attiva. Per disabilitarla:
<pre>Defaults !authenticate</pre>
<pre>Defaults !authenticate</pre>
Riga 512: Riga 519:
</pre>
</pre>


-passwd_tries
'''passwd_tries'''<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:
Di default è 3. Ciò vuol dire che si hanno tre tentativi per inserire correttamente la password prima che <code>sudo</code> termini con questo messaggio d'errore:
<pre>sudo: 3 incorrect password attempts</pre>
<pre>sudo: 3 incorrect password attempts</pre>
Questo valore può essere cambiato. Se si vogliono concedere cinque tentativi:
Questo valore può essere cambiato. Se si vogliono concedere cinque tentativi:
<pre>Defaults passwd_tries=5</pre>
<pre>Defaults passwd_tries=5</pre>


-passwd_timeout
'''passwd_timeout'''<br/>
È 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.
È il numero di minuti trascorsi i quali il prompt di immissione della password viene chiuso. Di default questo valore è 0, cioè <code>sudo</code> rimane indefinitivamente in attesa della password.
Per chiudere il prompt dopo tre minuti:
Per chiudere il prompt dopo tre minuti:
<pre>Defaults passwd_timeout=3</pre>
<pre>Defaults passwd_timeout=3</pre>
Riga 525: Riga 532:
<pre>Defaults passwd_timeout=3.1</pre>
<pre>Defaults passwd_timeout=3.1</pre>


-timestamp_timeout
'''timestamp_timeout'''<br/>
È il numero di minuti trascorsi i quali verrà nuovamente richiesta una password.
È il numero di minuti trascorsi i quali verrà nuovamente richiesta una password.<br/>
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.
Di default questo valore è 15. Ciò vuol dire che, dal momento in cui si inserisce correttamente una password, passeranno quindici minuti senza che <code>sudo</code> la richieda ancora.<br/>
Per fare in modo che venga sempre richiesta la password ogni volta che si utilizza ''sudo'':
<pre>Defaults timestamp_timeout=0</pre>
Per evitare che venga richiesta la password:
<pre>Defaults timestamp_timeout=-1</pre>
o assegnare all'opzione un qualunque valore negativo.


-badpass_message
'''badpass_message'''<br/>
Il messaggio che viene visualizzato quando si inserisce una password sbagliata. Di default è:
Il messaggio che viene visualizzato quando si inserisce una password sbagliata. Di default è:
<pre>Sorry, try again.</pre>
<pre>Sorry, try again.</pre>
Per cambiarla:
Per cambiarlo:
<pre>Defaults badpass_message="Password errata. Controlla che non sia stato premuto il tasto delle maiuscole."</pre>
<pre>Defaults badpass_message="Password errata. Controlla che non sia stato premuto il tasto delle maiuscole."</pre>


-insults
'''insults'''<br/>
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.
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.
I messaggi sono in inglese e non particolarmente offensivi; se volete messaggi in italiano o volete andarci giù pesante con le offese, ricompilatevi <code>sudo</code> con le modifiche apportate.
Di default questa opzione è disabilitata. Per abilitarla:
Di default questa opzione è disabilitata. Per abilitarla:
<pre>Defaults insults</pre>
<pre>Defaults insults</pre>


-pwfeedback
'''pwfeedback'''<br/>
Attiva il feedback per ogni tasto premuto durante l'inserimento della password. Tipicamente un asterisco. (TODO: come è impostato?)
Attiva il feedback per ogni tasto premuto durante l'inserimento della password. Tipicamente un asterisco.<!--(TODO: come è impostato?)-->
<pre>[sudo] password for pippo: *******</pre>
<pre>[sudo] password for pippo: *******</pre>
Per impostare questa opzione:
Per impostare questa opzione:
<pre>Defaults pwfeedback</pre>
<pre>Defaults pwfeedback</pre>
Questa opzione è disabilitata di default ed un amministratore di rete è invitato a non attivarla; un malintenzionato alle spalle dell'utente potrebbe ottenere informazioni sulla lunghezza della password.
Questa opzione è disabilitata di default ed un amministratore di rete è invitato a non attivarla; un malintenzionato alle spalle dell'utente potrebbe ottenere informazioni sulla lunghezza della password.<br/>
Su macchine desktop o portatilli, questo potrebbe essere invece un buon metodo da utilizzare per prevenire errori di immissione, soprattutto se la password è molto lunga e sempre che abbiate persone fidate o proprio nessuno alle spalle.
Su macchine desktop o portatili, questo potrebbe essere invece un buon metodo da utilizzare per prevenire errori di immissione, soprattutto se la password è molto lunga e sempre che abbiate persone fidate alle spalle.


-rootpw
'''rootpw'''<br/>
Con questa opzione viene chiesta la password di root anziché la password dell'utente che esegue sudo.  
Con questa opzione viene chiesta la password di root anziché la password dell'utente che esegue <code>sudo</code>.<br/>
Di default è disabilitata ed è fortemente sconsigliato abilitarla; sudo viene utilizzato proprio per evitare di digitare la password di root.
Di default è disabilitata ed è fortemente sconsigliato abilitarla; <code>sudo</code> viene utilizzato proprio per evitare di digitare la password di root.


-listpw
'''listpw'''<br/>
Controlla la richiesta della password quando un utente esegue il comando:
Controlla la richiesta della password quando un utente esegue il comando:
<pre>$ sudo -l</pre>
<pre>$ sudo -l</pre>
- all: la password non viene chiesta solo se tutte le entries che riguardano l'utente contengono il tag NOPASSWD
;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
;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
;always:la password viene sempre chiesta<br/>
- never: la password non viene mai chiesta. "listpw=never" è equivalente a "!listpw"
;never:la password non viene mai chiesta. "listpw=never" è equivalente a "!listpw"<br/>


Esempio1
Esempio1
Riga 572: Riga 584:
     (root) /usr/bin/tail /var/log/kern.log
     (root) /usr/bin/tail /var/log/kern.log
</pre>
</pre>


Esempio2
Esempio2
Come il precedente ma con listpw=all . Questa volta la password viene chiesta perché non tutte le entries hanno il tag NOPASSWD.
Come il precedente ma con "listpw=all" . Questa volta la password viene chiesta perché non tutte le entries hanno il tag NOPASSWD.
<pre>Defaults listpw=all
<pre>Defaults listpw=all
pippo ALL = NOPASSWD:/usr/bin/tail /var/log/syslog
pippo ALL = NOPASSWD:/usr/bin/tail /var/log/syslog
Riga 583: Riga 594:
[sudo] password for pippo:
[sudo] password for pippo:
</pre>  
</pre>  
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.
Il valore di default per questa opzione è "any". Il valore "always" può essere utilizzato dagli amministratori per impedire che, senza l'inserimento di una password, qualcuno possa risalire ai comandi eseguibili da un utente attraverso <code>sudo</code>.


-verifypw
'''verifypw'''<br/>
Identica alla precedente. L'unica differenza è che controlla la password richiesta per il comando:
Identica alla precedente. L'unica differenza è che controlla la password richiesta per il comando:
<pre>$ sudo -v</pre>
<pre>$ sudo -v</pre>
Il valore di default è "all".
Il valore di default è "all".


EMAIL /DA CONTROLLARE CON ESEMPI CONCRETI
EMAIL<br/>
-mailsub
'''mailsub'''<br/>
È il soggetto dell'email che verrà inviata in base ai criteri impostati. Di default è:
È il soggetto dell'email che verrà inviata in base ai criteri impostati. Di default è:
<pre>* * * SECURITY information for %h * * *</pre>
<pre>* * * SECURITY information for %h * * *</pre>
(TODO: gli escpae %)
<!--(TODO: gli escpape %)-->


-mailto
'''mailto'''<br/>
L'indirizzo di posta a cui verrà inviata l'email. Racchiudere tra doppie virgolette se contiene il carattere @ . Di default l'emailviene inviata a root.
L'indirizzo di posta a cui verrà inviata l'email. Racchiudere tra doppie virgolette se contiene il carattere @ . Di default l'email viene inviata a root.
(TODO: posta locale)
<!--(TODO: posta locale)-->


-mailfrom
'''mailfrom'''<br/>
L'indirizzo da cui verrà inviata l'email. Di default è l'indirizzo dell'utente che esegue sudo.
L'indirizzo da cui verrà inviata l'email. Di default è l'indirizzo dell'utente che esegue <code>sudo</code>.
(TODO)
<!--(TODO)-->


-mailerpath
'''mailerpath'''<br/>
Il path del programma utilizzato per inviare le email. Di default è "/usr/sbin/sendmail" che, in una installazione di default di Debian, è un link che punta a Exim.
Il path del programma utilizzato per inviare le email. Di default è "/usr/sbin/sendmail" che, in una installazione di default di Debian, è un link che punta a Exim.


-mailerflags
'''mailerflags'''<br/>
I flag da applicare al programma specificato in mailerpath.
I flag da applicare al programma specificato in mailerpath.<br/>
Di default questa variabile è impostata a "-t", cioè fa in modo che il programma di posta possa lavorare con indirizzi locali.
Di default questa variabile è impostata a "-t", cioè fa in modo che il programma di posta possa lavorare con indirizzi locali.


-mail_always
'''mail_always'''<br/>
Viene inviata una email ogni volta che un utente esegue sudo. Di default questa opzione è disabilitata.
Viene inviata una email ogni volta che un utente esegue <code>sudo</code>. Di default questa opzione è disabilitata. Per abilitarla:
Per abilitarla:
<pre>Defaults mail_always</pre>
<pre>Defaults mail_always</pre>


-mail_badpass
'''mail_badpass'''<br/>
Viene inviata una email se l'utente inserisce una password sbagliata. Di default è disabilitata.
Viene inviata una email se l'utente inserisce una password sbagliata. Di default è disabilitata. Per attivarla:
Per attivarla:
<pre>Defaults mail_badpass</pre>
<pre>Defaults mail_badpass</pre>


-mail_no_host
'''mail_no_host'''<br/>
Viene inviata una email se l'utente è abilitato ad eseguire sudo ma non sull'host specificato. Questa opzione è disabilitata di default.
Viene inviata una email se l'utente è abilitato ad eseguire <code>sudo</code> ma non sull'host specificato. Questa opzione è disabilitata di default. Per abilitarla:
Per abilitarla:
<pre>Defaults mail_no_host</pre>
<pre>Defaults mail_no_host</pre>
Esempio:
Esempio:
<pre>Defaults mail_no_host
<pre>Defaults mail_no_host
pippo localhost = /usr/bin/tail /var/log/kern.log_host
pippo localhost = /usr/bin/tail /var/log/kern.log_host
</pre>
</pre>
L'email verrà inviata se l'utente pippo si collegherà dall'host sds.dsds.sds e proverà ad eseguire:
L'email verrà inviata se l'utente pippo si collegherà da remoto (quindi non su "localhost") e proverà ad eseguire:
<pre>$ sudo /usr/bin/tail 7var/log/kern.log</pre>
<pre>$ sudo /usr/bin/tail /var/log/kern.log</pre>


-mail:no_perms
'''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.
Viene inviata una email se l'utente ha i permessi di eseguire comandi attraverso <code>sudo</code> ma cerca di eseguire altri comandi non consentiti. Di default questa opzione è disabilitata.
Per abilitarla:
Per abilitarla:
<pre>Defaults mail_no_perms</pre>
<pre>Defaults mail_no_perms</pre>
Riga 642: Riga 650:
Verrà inviata una email se pippo prova a:
Verrà inviata una email se pippo prova a:
<pre>$ sudo /usr/bin/tail /var/log/syslog</pre>
<pre>$ sudo /usr/bin/tail /var/log/syslog</pre>
ma non se pippo prova ad eseguire lo stesso comando ma con sudoers impostato in questo modo:
ma non se pippo prova ad eseguire lo stesso comando ma con <code>sudoers</code> impostato in questo modo:
<pre>Defaults mail_no_perms
<pre>Defaults mail_no_perms
pluto ALL : /usr/bin/tail /var/log/kern.log
pluto ALL : /usr/bin/tail /var/log/kern.log
Riga 648: Riga 656:
poiché non si trova nelle entries del file. La prossima opzione abilita questo comportamento.
poiché non si trova nelle entries del file. La prossima opzione abilita questo comportamento.


-mail_no_user
'''mail_no_user'''<br/>
Viene inviata una email se l'utente che esegue sudo non è presente nel file sudoers. Questa opzione è abilitata di default.
Viene inviata una email se l'utente che esegue <code>sudo</code> non è presente nel file <code>sudoers</code>. Questa opzione è abilitata di default. Per disabilitarla (sconsigliato):
Per disabilitarla (sconsigliato):
<pre>Defaults !mail_no_user</pre>
<pre>Defaults !mail_no_user</pre>
L'esempio è il contrario dell'esempio preacedente:
L'esempio è il contrario dell'esempio precedente:
<pre>
<pre>
pippo ALL : /usr/bin/tail /var/log/kern.log
pippo ALL : /usr/bin/tail /var/log/kern.log
Riga 660: Riga 667:
Ma non se pippo prova ad eseguire il comando:
Ma non se pippo prova ad eseguire il comando:
<pre>$ sudo /usr/bin/tail /var/log/syslog</pre>
<pre>$ sudo /usr/bin/tail /var/log/syslog</pre>
a meno che non sia abilitata mail_no_perms .
a meno che non sia abilitata "mail_no_perms" .


È opportuno, almeno all'inizio, abilitare tutte queste opzioni:
È opportuno, almeno all'inizio, abilitare tutte queste opzioni:
<pre>Defaults mail_always, mail_badpass, mail_no_host, mail_no_perms</pre>
<pre>Defaults mail_always, mail_badpass, mail_no_host, mail_no_perms</pre>
in modo da rendersi conto di come viene utilizzato sudo dagli utenti della propria rete e, quindi, apportare le opportune correzioni.
in modo da rendersi conto di come viene utilizzato <code>sudo</code> dagli utenti della propria rete e, quindi, apportare le opportune correzioni.
 
<!--
PATH & ENVIRONMENT VARIABLES
PATH & ENVIRONMENT VARIABLES
Qui verrà trattato un aspetto particolarmente importante legato alla sicurezza: le variabili d'ambiente.
Qui verrà trattato un aspetto particolarmente importante legato alla sicurezza: le variabili d'ambiente.
Riga 676: Riga 683:


Facciamo un esempio.
Facciamo un esempio.
Supponiamo che l'utente gambadilegno abbia una variabile d'ambiente così definita nel proprio .bashrc :
Supponiamo che l'utente gambadilegno abbia una variabile d'ambiente così definita nel proprio .bashrc : -->
 
 
== Esempi ==
In questo paragrafo saranno raccolti gli esempi che descrivono come utilizzare <code>sudo</code> per compiti specifici e che possono essere di qualche utilità per l'utente.<br/>
Queste operazioni non sono obbligatorie e vanno vagliate e adattate con attenzione alle proprie esigenze per evitare di aprire falle di sicurezza del sistema.
 
Si ricorda che:
* Il nome del proprio host può essere ricavato attraverso il comando "hostname"
* Il [[path]] del comando va trovato con "whereis -b comando". Ad esempio:<pre>$ whereis -b less &#10;less: /bin/less /usr/bin/less /usr/bin/X11/less</pre>
 
=== Modificare file ===
La modifica di file di sistema (normalmente riservata a root) è sicuramente il compito più diffuso per cui viene utilizzato <code>sudo</code>.<br/>
Con questa configurazione utilizzeremo "sudoedit" per la modifica dei file di sistema utilizzando il nostro [[Impostare l'editor predefinito della shell|editor di default]].
<pre>
...
Cmnd_Alias EDITFILE = sudoedit /etc/apt/sources.list, \
                      sudoedit /etc/network/interfaces, \
                      sudoedit /etc/default/apache2
 
pippo miolocalhost = NOEXEC:EDITFILE
...
</pre>
In qusto modo all'utente "pippo" sarà concesso modificare i file scelti, utilizzando l'editor di default dal solo host "miolocalhost", previo inserimento della propria password. Il comando sarà:
<pre>
$ sudoedit /etc/apt/sources.list
</pre>
o:
<pre>
$ sudo -e /etc/apt/sources.list
</pre>
Prestare particolare attenzione ai file scelti: quelli indicati sono soltanto un esempio.
 
=== Leggere i file di <code>/var/log/</code> ===
I file di log di sistema che si trovano nella directory <code>/var/log/</code> non sono accessibili ad un normale utente ma solo ai membri del gruppo "adm" e, ovviamente, a [[root]].<br/>
Questa configurazione consentirà di leggere, attraverso il [[pager]] "less", alcuni file di log. Si noti che in questo modo si previene la modifica dei file e, principalmente, si consente la lettura solo per alcuni di essi.<br/>
Con il seguente esempio non viene chiesta alcuna password attraverso l'uso del tag "NOPASSWD".
<pre>
...
Cmnd_Alias LETTURALOG = /bin/less /var/log/messages, \
                        /bin/less /var/log/kern.log, \
                        /bin/less /var/log/syslog
 
pippo miolocalhost = NOPASSWD:LETTURALOG
...
</pre>
In questo modo l'utente "pippo" potrà eseguire, esclusivamente dall'[[host]] "miolocalhost", i comandi:
<pre>
$ sudo less /var/log/messages
$ sudo less /var/log/kern.log
$ sudo less /var/log/syslog
</pre>
per leggere i file "messages", "kern.log" o "syslog".
 
Un'alternativa è leggere i log con le credenziali del gruppo "adm" (che ha i permessi di sola lettura per questi file) anziché di root:
<pre>
...
Cmnd_Alias LETTURALOG = /bin/less /var/log/messages, \
                        /bin/less /var/log/kern.log, \
                        /bin/less /var/log/syslog
 
pippo miolocalhost = (:adm) NOPASSWD:LETTURALOG
...
</pre>
e utilizzare, ad esempio, il comando:
<pre>
$ sudo -g adm less /var/log/syslog
</pre>
Questo secondo metodo può essere molto utile nel caso in cui l'utente a cui vengono concessi i permessi di lettura non si trovi a particolare agio con "less" ma voglia utilizzare un editor. In questo caso è opportuno che l'utente esegua il comando con i permessi del gruppo "adm" e che, quindi, non abbia la possibilità di modificare i file letti.<br/>
Un esempio potrebbe essere:
<pre>
...
Cmnd_Alias LETTURALOG = sudoedit /var/log/messages, \
                        sudoedit /var/log/kern.log, \
                        sudoedit /var/log/syslog
 
pippo miolocalhost = (:adm) NOPASSWD:NOEXEC:LETTURALOG
...
</pre>
e il conseguente comando permesso attraverso <code>sudo</code> per leggere, ad esempio, il file <code>/var/log/messages</code> sarà:
<pre>
$ sudoedit -g adm /var/log/messages
</pre>
 
=== Aggiornare la lista dei pacchetti ===
L'aggiornamento della lista dei pacchetti con:
<pre># apt-get update</pre>
è un compito riservato all'amministratore di sistema ma può essere invocato con relativa sicurezza da un normale utente.
 
Le seguenti modifiche consentiranno all'utente "pippo" di aggiornare la lista dei pacchetti con [[apt-get]] senza inserire alcuna password.
<pre>
...
Cmnd_Alias AGGIORNAMENTO = /usr/bin/apt-get update
 
pippo miolocalhost = NOPASSWD:AGGIORNAMENTO
...
</pre>
L'aggiornamento sarà consentito solo se il comando è eseguito sull'host "miolocalhost" con:
<pre>
$ sudo apt-get update
</pre>
 
{{Autori
|Autore = [[Utente:S3v|S3v]]
|Verificata_da=
:[[Utente:Wtf|Wtf]] 16:10, 5 mag 2024 (CEST)
|Estesa_da =
:[[Utente:Wtf|Wtf]] 16:10, 5 mag 2024 (CEST)
|Numero_revisori=1
}}
 
[[Categoria: Programmi da terminale]]

Versione attuale delle 14:20, 5 mag 2024

Debian-swirl.png Versioni Compatibili

Tutte le versioni supportate di Debian

Prima di iniziare

Mi serve sudo?

La risposta è, come sempre, "dipende".

Se non sai qual è la sua funzione o come si configura, probabilmente non ti serve.
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.
Sudo permette all'amministratore del server di concedere privilegi di esecuzione per comandi ben precisi e solo ad utentu (o host) ben definiti.
Il tutto si traduce in una maggiore flessibilità nelle operazioni di gestione della macchina.

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

Errori comuni

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

Rimuovere l'autenticazione
La rimozione dell'autenticazione (vedere l'opzione "authenticate") è, di per sé, un'operazione generalmente da evitare in quanto, senza ulteriori configurazioni, elimina la richiesta di inserimento password per un utente che, attraverso sudo, esegue un comando (o più comandi). Inoltre è foriera di sicuri errori di configurazione quando il file /etc/sudoers contiene numerose linee.
In congiunzione con uno dei due errori descritti in precedenza, però, questa operazione assume i caratteri del cataclisma: chiunque può eseguire comandi di sistema attraverso sudo, da qualunque parte del mondo si trovi e senza nessuna password da immettere. L'unica limitazione sarà l'accesso (fisico o remoto) al vostro host.
Modifiche frequenti ai file
Se modificate frequentemente i file di sistema, potrebbe sorgere l'illusoria esigenza di dover installare sudo.
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.
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).
Sudo semplifica l'amministrazione
Sudo semplifica l'amministrazione del sistema solo se si sa esattamente quali sono le proprie esigenze e come si modifica correttamente il file /etc/sudoers .
Se pensate che 'semplificare' coincida con il dimenticarsi della password di root (o, peggio ancora, con il non averla), siete fuori strada e, probabilmente, Debian non è la distribuzione che fa per voi.
Sudo e l'escape della shell
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.
Consideriamo la seguente riga in /etc/sudoers:
pippo ALL = /usr/bin/vim /etc/apt/sources.list
in buona fede si potrebbe pensare di concedere all'utente pippo la sola modifica del file /etc/apt/sources.list attraverso Vim. Malauguratamente Vim, e altri programmi, permettono di eseguire una shell (vedere [Vim Cheat Sheet|qui]). Per cui l'utente pippo, un volta eseguito il comando:
$ sudo vim /etc/apt/sources.list
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.
La soluzione è modificare il file sudoers così:
pippo localhost = NOEXEC : /usr/bin/vim /etc/apt/sources.list
o utilizzare altro editor (nano) che non permetta l'escape della shell.
Modifica dei file
La precedente riga:
pippo localhost = NOEXEC : /usr/bin/vim /etc/apt/sources.list
effettivamente impedisce che Vim possa eseguire una shell. Il problema è che non impedisce che Vim possa aprire un altro file e modificarlo. Oppure creare un file in un punto qualunque del filesystem.
La soluzione è utilizzare sudoedit:
pippo localhost = NOEXEC : sudoedit /etc/apt/sources.list

Consigli utili

  • Non installare sudo su macchine desktop.
    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.
    Documentarsi anche sul funzionamento di ogni programma che si è deciso di avviare attraverso sudo.
  • Utilizzare sudoedit anziché direttamente programmi che permettono l'escape della shell
  • Utilizzare sudoedit ogni volta che si vuol editare un file.
  • Tenere sempre presente che la priorità è la sicurezza della Debian box.
    In un mondo interconnesso, la compromissione della sicurezza della vostra macchina non è solo un problema per voi stessi ma anche un serio problema per ogni computer del globo.
  • Valutare attentamente i vantaggi e gli svantaggi a cui si va incontro utilizzando sudo.

Installazione

Sudo, contrariamente a quanto si possa pensare, non è uno strumento essenziale per la configurazione del sistema e non viene installato di default in Debian. Per installarlo, è necessario impartire esplicitamente un:

# apt-get install sudo

a meno che, durante l'installazione, non si sia scelto di lasciare vuota la password di root.

Warning.png ATTENZIONE
L'esistenza della password di root rappresenta una delle forme minime di sicurezza per il sistema. Non assegnare una password a root è fortemente sconsigliato. Chi decide di farlo, ne accetta le conseguenze e i rischi legati alla sicurezza.


Se si vuole riavere una password di root non vuota, basta eseguire:

$ sudo passwd root

e poi rimuovere il proprio utente dal gruppo sudo:

# deluser nome_utente 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.

Configurazione

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

Il file /etc/sudoers

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

# visudo

In questo modo viene eseguito l'editor di default, rigorosamente testuale.

Il file all'inizio si presenta così:

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo  ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

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.
L'ultima linea, in cui è contenuta la direttiva "#includedir", rappresenta un'eccezione alla regola precedente e non viene vista come un commento.

Prestare attenzione al fatto che aggiornamenti del pacchetto sudo potrebbero chiedere di sovrascrivere questo file.
Benché in fase di aggiornamento gli avvertimenti siano piuttosto chiari (verrà chiesto esplicitamente se mantenere il file, se sovrascriverlo, guardare i cambiamenti introdotti etc.), è consigliato creare una copia di backup e custodirla al sicuro.

La directory /etc/sudoers.d/

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:
    #includedir /etc/sudoers.d
  • I file non possono contenere punti nel loro nome
  • I file che terminano con ~ non vengono considerati
  • È opportuno dare i permessi 0440 a questi file:
    # chmod 0440 /etc/sudoers.d/*
    in modo che siano leggibili e scrivibili solo da root
  • I file sono letti in ordine alfabetico. Si consiglia di anteporre un numero al loro nome in modo da avere la certezza che i file vengano letti nell'ordine desiderato. Ad esempio: 00topolino, 01pippo, 02 pluto, .... , 99gambadilegno
  • 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.
  • Suddividere i file in maniera logica (per utente, per host, per gruppi, per comandi, etc.) e commentare ogni aggiunta o modifica. Questo consentirà, sia a voi sia a chi si troverà a leggerli, di interpretarli con maggior semplicità e chiarezza
  • A differenza del file sudoers, è possibile creare e modificare questi file con un editor grafico attraverso "gksu" o "kdesu"
    $ gksu gedit /etc/sudoers.d/01pippo
  • Tutti i file presenti in questa directory non saranno sovrascritti o cancellati da futuri aggiornamenti del pacchetto sudo

Leggere anche il file /etc/sudoers.d/README

Struttura

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

Opzioni di default

Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Alias

# Host alias specification
 
# User alias specification
 
# Cmnd alias specification

inizialmente vuoto.

Specifiche

root    ALL=(ALL:ALL) ALL
%sudo  ALL=(ALL:ALL) ALL

Direttiva #includedir

#includedir /etc/sudoers.d

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.

Le prime tre sezioni verranno analizzate separatamente ed è raccomandato mantenerle separate e nell'ordine indicato. Benché sia possibile mescolare gli alias con le specifiche e con le opzioni di default, il risultato sarebbe solo quello di rendere illeggibile il file di configurazione e, spesso, sperimentare comportamenti indesiderati.

Specifiche

Eccoci giunti al cuore del file sudoers: le righe che indicano in che modo e con quali comandi è possibile invocare sudo.
Una riga è costituita da diversi parametri strutturati in questo modo:

CHI HOST=(ALTRO_UTENTE:ALTRO_GRUPPO) EVENTUALI_TAG:COMANDO

I parametri obbligatori sono:

  • CHI, cioè il nome dell'utente linux cui è consentito eseguire sudo
  • HOST, cioè il luogo da cui è permesso eseguire sudo
  • Il carattere =
  • COMANDO, cioè il comando che CHI può eseguire, avendo cura di specificarlo dandone il percorso (path) assoluto (/path/to/command).

I parametri facoltativi sono:

  • ALTRO_UTENTE e ALTRO_GRUPPO permettono di specificare con che nome utente e gruppo il comando dovrà essere eseguito. Omettere questi due parametri significa dire implicitamente al sistema che il comando deve essere eseguito con i privilegi di root (il comportamento desiderato nella maggior parte dei casi). Se però si decide di specificarli è necessario specificare entrambi i parametri come sopra indicato, ovvero racchiudendoli tra parentesi e separandoli col carattere :..
  • EVENTUALI_TAG. Devono essere inseriti prima del comando a cui si applicano e separati da questo da un carattere :

Di seguito un semplice esempio del tutto teorico:

pippo topolinia = (topolino:topolino) NOPASSWD:/path/assoluto/del/comando

Questa riga indica che l'utente pippo (CHI) potrà eseguire il comando solo dall'host "topolinia" e con le credenziali dell'utente topolino (ALTRO_UTENTE) e del gruppo topolino (ALTRO_GRUPPO) senza richiedere la password di pippo prima di eseguire il comando (NOPASSWD è proprio uno degli EVENTUALI_TAG che è possibile dichiarare).

Chi

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.
Quindi se:

User_Alias DISNEY = cenerentola, biancaneve

pippo ALL = comando
%topolia ALL = comando2
+paperopoli ALL = comando3
DISNEY ALL = comando4

L'utente pippo può eseguire il comando:

$ sudo comando

L'utente topolino può eseguire:

sudo comando2

ma solo se fa parte del gruppo "topolinia".
L'utente paperino può eseguire:

$ sudo comando3

ma solo se fa parte del gruppo di rete "paperopoli".
Biancaneve e cenerentola possono eseguire:

$ sudo comando4

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

Sorry, user nomeutente is not allowed to execute comando as root on nomehost.

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

Un esempio funzionante è il seguente:

pippo ALL = /usr/bin/ifconfig -a

con cui pippo può eseguire un comando che richiede i permessi di root:

$ sudo ifconfig -a

questo visualizzerà le interfacce di rete previo inserimento da parte di pippo della propria password.

Da dove

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.
La parola "ALL" indica che gli utenti potranno eseguire sudo da qualsiasi host.
Lo scopo di questa voce è chiaro, magari si vuol consentire a pippo di eseguire sudo solo da una macchina della rete locale:

pippo 192.168.1.80 = comando

A questo proposito è sempre opportuno specificare l'IP o l'host e non utilizzare la parola "ALL". Il nome dell'host si può ricavare con il comando:

$ hostname

Ad esempio:

$ hostname
pippohost

e la configurazione sarà:

pippo pippohost = comando

Tag

I tag utilizzati da sudo precedono immediatamente il path assoluto del comando e sono separati da questo da un carattere di ":". Ad esempio:

utente host = TAG:comando

Sono permessi più tag, in questo caso è necessario separarli con un carattere ":", ad esempio:

utente host = TAG1:TAG2:comando

I tag consentiti sono dieci:

  • PASSWD e NOPASSWD
  • EXEC e NOEXEC
  • SETENV e NOSETENV
  • LOG_INPUT e NOLOG_INPUT
  • LOG_OUTPUT e NOLOG_OUTPUT

Questi tag, come si può notare, compongono delle coppie duali in cui un tag della coppia può sovrascrivere una precedente impostazione creata dall'altro componente della coppia.

Dovrebbe essere facilmente intuibile l'assoluta inutilità, benché sia consentito farlo, di specificare tag duali sulla stessa riga. Ad esempio:

utente host = PASSWD:NOPASSWD:comando

Questa notazione è assolutamente identica a:

utente host = NOPASSWD:comando

in quanto il tag che crea l'impostazione sovrascrive l'impostazione creata dal tag duale. In questo caso, quindi, avrà effetto solo l'impostazione creata dal tag della coppia che viene scritto per ultimo.


Alias

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.

Come lascia intuire il nome, gli alias permettono di raggruppare logicamente il nome di un certo numero di utenti, di host, di gruppi o di comandi, in modo da farvi riferimento in modo semplice e veloce attraverso una sola stringa identificativa (il nome dell'alias).
Facciamo un esempio non realistico.
Supponiamo di avere una configurazione che contiene:

pippo ALL = /usr/bin/rm /tmp/tempdir/*
pippo ALL = /usr/bin/rm /log/app/*
pippo ALL = /usr/bin/rm /media/share/temp/*

con cui l'utente pippo ha il permesso di cancellare determinati file. Che accade se l'amministratore di sistema decide di concedere gli stessi permessi all'utente pluto? O se decide di togliere i permessi a pippo e di darli a pluto? O se vuole modificare il comando "rm" passandogli un'opzione? Con questa configurazione dovrà modificare una per una tutte le linee (nell'esempio sono tre, ma potrebbero essere molte di più).
La soluzione è ricorrere agli alias:

User_Alias UTENTI_RM = pippo
Cmnd_Alias COMANDO_RM = "/usr/bin/rm"

UTENTI_RM ALL = COMANDO_RM /tmp/tempdir/*
UTENTI_RM ALL = COMANDO_RM /log/app/*
UTENTI_RM ALL = COMANDO_RM /media/share/temp/*

A questo punto, se si vogliono concedere gli stessi permessi a pluto:

User_Alias UTENTI_RM = pippo, pluto
Cmnd_Alias COMANDO_RM = "/usr/bin/rm"

UTENTI_RM ALL = COMANDO_RM /tmp/tempdir/*
UTENTI_RM ALL = COMANDO_RM /log/app/*
UTENTI_RM ALL = COMANDO_RM /media/share/temp/*

Se si vuol cambiare anche il comando:

User_Alias UTENTI_RM = pippo, pluto
Cmnd_Alias COMANDO_RM = "/usr/bin/rm -rf"

UTENTI_RM ALL = COMANDO_RM /tmp/tempdir/*
UTENTI_RM ALL = COMANDO_RM /log/app/*
UTENTI_RM ALL = COMANDO_RM /media/share/temp/*

si può notare che la modifica avviene in un solo punto del file con le ultime tre righe che restano invariate.

Sintassi degli alias

La sintassi è:

Tipo_di_alias NOME_ALIAS = Lista
Tipo_di_alias
Ciacuna riga che identifica un alias deve iniziare necessariamente con una parola che stabilisce il tipo di alias che stiamo creando. Questa parole sono quattro:
- User_Alias
- Runas_Alias
- Host_Alias
- Cmnd_Alias
e vanno scritte esattamente in questa forma.
Nome alias
Questa è la stringa a cui potrà farà riferimento in altri alias o nelle specifiche.
- Deve essere composto da lettere maiuscole, lettere minuscole o caratteri di underscore "_" . Altri caratteri non sono ammessi.
- Deve necessariamente iniziare con una lettera maiuscola
- Per maggiore chiarezza è una buona idea scriverlo in sole lettere maiuscole
Lista
A differenza del tipo e del nome dell'alias, la scrittura di una lista è leggermente più articolata e dipende dal tipo di alias specificato. Gli elementi che compongono una lista devono essere separati da una virgola e vanno quotati tra doppie virgolette se contengono caratteri speciali; la lista può contenere anche altri alias purché questi siano già stati definiti. Ad esempio:
User_Alias UTENTI1 = pippo, pluto
User_Alias UTENTI2 = paperino, gastone, UTENTI1

UTENTI2 ALL = /usr/bin/tail /var/log/syslog

e gli utenti pippo e pluto possono visualizzare le ultime righe del file /var/log/syslog .

Alias di tipo User_Alias

Una lista di questo tipo è composta da uno o più nomi utente, UID, gruppi, gruppi di rete, gruppi di tipo "nonunix" o altri alias di tipo User_Alias.
I nomi utente (username) vanno scritti "as is", seguendo la distinzione maiuscole/minuscole (Pippo e pippo sono utenti diversi).
Gli UID identificano un utente e vanno preceduti da un carattere cancelletto "#" (ad es. #1000, #1001, #1002).
I gruppi sono preceduti dal carattere di percentuale (%) e sono quelli letti nel file /etc/group (ad es. %adm, %src, %plugdev).
Gli alias di tipo User_Alias vanno scritti con il loro nome e devono essere stati definiti in precedenza.

Esempio 1

User_Alias PAPEROPOLI = paperoga, paperina, gastone
PAPEROPOLI ALL = /usr/bin/ifconfig -a > ifconfig.txt

gli utenti paperoga, paperina e gastone possono creare un file nella directory corrente con l'output del comando "ifconfig -a' .

Esempio 2

User_Alias FANTASY = %robot, !goldrake, godzilla
FANTASY ALL = /bin/rm /tmp/tempdir/*

tutti i file della directory "/tmp/tempdir" possono essere cancellati solo dagli utenti che fanno parte del gruppo "robot", dall'utente godzilla (anche se non fa parte del gruppo "robot") ma non dall'utente goldrake (anche se fa parte del gruppo "robot")

Esempio 3

User_Alias TOPOLINIA = topolino, #1005, %bandabassotti, minnie, !371-173
TOPOLINIA ALL = /myscripts/backup.sh

gli utenti topolino e minnie, gli utenti che fanno parte del gruppo "bandabassotti" e l'utente con UID uguale a 1005 possono eseguire uno script di backup.
Non può eseguire lo script l'utente 371-173 anche se fa parte del gruppo "bandabassotti".

Esempio 4

User_Alias PAPEROPOLI = paperoga, paperina
User_Alias NIPOTI_DI_PAPERINO = qui, quo, qua
User_Alias DISNEY = %biancaneve, #1001, PAPEROPOLI, NIPOTI_DI_PAPERINO, !paperoga, !quo

DISNEY ALL = NOEXEC:/usr/bin/vim /etc/apt/sources.list

il file /etc/apt/sources.list può essere modificato solo dall'utente con UID uguale a 1001, da paperina, dagli utenti del gruppo biancaneve, da qui e da qua. Non può essere modificato da paperoga e quo.

Alias di tipo Host_Alias

In questa lista possono essere compresi nomi di host, indirizzi IP, indirizzi di rete con relativa submask (sia in formato standard che con la notazione CIDR), gruppi di rete (preceduti dal carattere "+") o altri alias di tipi Host_Alias.
Il carattere "!" nega un elemento della lista come nel caso precedente.

Ad esempio:

Host_Alias TRUSTED = server1, 192.168.1.23, 10.0.0.0/24, +grupporete

Alias di tipo Cmnd_Alias

Lista che contiene uno o più comandi o directory.

  • I comandi devono essere scritti esattamente insieme al loro path assoluto ("whereis nomecomando" per trovarlo)
  • I comandi funzionano anche se vengono eseguiti insieme a dei parametri, per cui se:
Cmnd_Alias LS = /bin/ls
pippo	ALL = LS

il seguente comando non produrrà un errore:

$ sudo ls -l

Per evitare questo comportamento e consentire che il comando venga eseguito solo senza parametri, bisogna far seguire "" al comando:

 Cmnd_Alias LS = /bin/ls ""

in questo modo sarà consentito solo:

$ sudo ls

ma non:

$ sudo ls -l

Se si vogliono consentire solo determinati parametri, bisogna ricorrere ai metacaratteri. Ad esempio, per consentire i comandi "ls -l" e "ls -a" ma non "ls -d":

Cmnd_Alias LS = /bin/ls -[la]
pippo	ALL = LS
  • È 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:
Cmnd_Alias BIN = /bin/
pippo	ALL = BIN

è possibile eseguire con sudo tutto ciò che si trova in /bin/. Ad esempio il comando "cat":

$ sudo cat /var/log/kern.log

Alias di tipo Runas_Alias

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. Ad esempio:

Runas_Alias AMICI = pippo, pluto, %adm
paperino ALL = (AMICI) /usr/local/bin/script.sh

E paperino potrà eseguire:

$ sudo -u pippo /usr/local/bin/script.sh
$ sudo -u pluto /usr/local/bin/script.sh

ma anche:

$ sudo -u topolino /usr/local/bin/script.sh

se l'utente topolino fa parte del gruppo adm.
Ovviamente tutti gli utenti coinvolti devono avere il permesso di eseguire lo script.

Opzioni

lecture
Visualizza un avvertimento prima che un utente esegua un comando attraverso sudo. I possibili valori sono:
- always: l'avvertimento viene sempre visualizzato
- never: l'avvertimento non viene mai visualizzato
- once: l'avvertimento viene visualizzato solo la prima volta che un utente esegue sudo

Di default l'avvertimento è:

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Ad esempio:

Defaults	lecture=always

stampa sempre un avvertimento.
Queste due righe sono equivalenti:

Defaults	lecture=never
Defaults	!lecture

lecture_file
L'avvertimento di default può essere cambiato con questa opzione. Ad esempio, se l'avvertimento è contenuto nel file /etc/sudo_lecturefile :

Defaults	lecture=always
Defaults	lecture_file="/etc/sudo_lecturefile"

passprompt
Permette di definire il prompt che verrà visualizzato alla richiesta password. Di default questo valore è impostato a:

[sudo] password for %p: 

È possibile ricorrere a qualche carattere speciale
-%H : il nome dell'host (FQDN)
-%h : host non FQDN
-%p : l'utente la cui password viene richiesta (%p può essere diverso dall'utente che esegue sudo)
-%U : l'utente con i cui permessi verrà eseguito il comando (di default è root)
-%u : l'utente che esegue il comando attraverso sudo
Ad esempio:

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

LOG
logfile
Per il file di log per sudo, di default, viene utilizzato /var/log/syslog. È 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.
Creare il file di log:

# touch /var/log/sudo.log

e poi, in /etc/sudoers :

Defaults	logfile="/var/log/sudo.log"

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

Defaults	log_host

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

Defaults	log_year

loglinelen
Lunghezza delle linee del file di log. La lunghezza di default è 80 caratteri, superata la quale la linea viene tagliata sulla riga successiva. Per disabilitare questo comportamento:

Defaults	!loglinelen

o, in alternativa:

Defaults	loglinelen=0

Per impostare, invece, una diversa lunghezza:

Defaults	loglinelen=120

log_input
Tutti gli input dell'utente attraverso una sessione sudo verranno loggati nella directory /var/log/sudo-io/. Ciascun file di questa directory ha un nome univoco in base al TSID (Terminal Session ID).
Questa opzione è disabilitata di default. Per abilitarla:

Defaults   log_input

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

# zless /var/log/sudo-io/00/00/01/ttyin

log_output
Tutti i messaggi visualizzati a schermo in una sessione sudo saranno loggati nella directory /var/log/sudo-io/, anche questi in base al TSID.
Questa opzione è disabilitata di default. Per abilitarla:

Defaults	log_output

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. Ad esempio, se si vuol vedere ciò che ha visto l'utente pippo (e quindi anche ciò che ha digitato se è stato stampato a schermo) durante la sessione TSID=nnnnnn, si può innanzitutto trovare il TSID (supponiamo che sia 000003):

# sudoreplay -l user pippo
...
mar  7 15:23:44 2013 : pippo : TTY=/dev/pts/1 ; CWD=/home/pippo ; USER=root ; TSID=000003 ; COMMAND=/bin/bash
...

e poi replicare la sessione sul proprio terminale:

# sudoreplay 000003

vedere:

man sudoreplay

per ottenere maggiori informazioni sul funzionamento di sudoreplay.

Info.png Nota
Nel caso abbiate la possibilità di utilizzare sudo su una macchina diversa dalla vostra, informatevi sulle politiche adottate dall'amministratore della macchina remota in merito alla gestione dei log di sudo. In ogni caso prestate attenzione all'inserimento, in sessioni sudo, di password o di qualunque altra informazione sensibile.


PASSWORD
authenticate
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.
Di default questa opzione è attiva. Per disabilitarla:

Defaults	!authenticate

oppure:

Defaults	authenticate=0

Esempio:

Defaults	!authenticate
pippo	ALL = PASSWD:/usr/bin/tail /var/log/syslog
pippo	ALL = /usr/bin/tail /var/log/kern.log

Verrà chiesta la password solo se viene eseguito il comando:

$ sudo /usr/bin/tail /var/log/syslog

Lasciare questa opzione abilitata ed, eventualmente, utilizzare il tag NOPASSWD. La configurazione sarà più chiara e preserverà dal commettere errori. L'esempio precedente diventerà così:

pippo	ALL = /usr/bin/tail /var/log/syslog
pippo	ALL = NOPASSWD:/usr/bin/tail /var/log/kern.log

passwd_tries
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:

sudo: 3 incorrect password attempts

Questo valore può essere cambiato. Se si vogliono concedere cinque tentativi:

Defaults	passwd_tries=5

passwd_timeout
È 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. Per chiudere il prompt dopo tre minuti:

Defaults	passwd_timeout=3

o dopo tre minuti e sei secondi:

Defaults	passwd_timeout=3.1

timestamp_timeout
È il numero di minuti trascorsi i quali verrà nuovamente richiesta una 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 fare in modo che venga sempre richiesta la password ogni volta che si utilizza sudo:

Defaults	timestamp_timeout=0

Per evitare che venga richiesta la password:

Defaults	timestamp_timeout=-1

o assegnare all'opzione un qualunque valore negativo.

badpass_message
Il messaggio che viene visualizzato quando si inserisce una password sbagliata. Di default è:

Sorry, try again.

Per cambiarlo:

Defaults	badpass_message="Password errata. Controlla che non sia stato premuto il tasto delle maiuscole."

insults
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".
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. Di default questa opzione è disabilitata. Per abilitarla:

Defaults	insults

pwfeedback
Attiva il feedback per ogni tasto premuto durante l'inserimento della password. Tipicamente un asterisco.

[sudo] password for pippo: *******

Per impostare questa opzione:

Defaults	pwfeedback

Questa opzione è disabilitata di default ed un amministratore di rete è invitato a non attivarla; un malintenzionato alle spalle dell'utente potrebbe ottenere informazioni sulla lunghezza della password.
Su macchine desktop o portatili, questo potrebbe essere invece un buon metodo da utilizzare per prevenire errori di immissione, soprattutto se la password è molto lunga e sempre che abbiate persone fidate alle spalle.

rootpw
Con questa opzione viene chiesta la password di root anziché la password dell'utente che esegue sudo.
Di default è disabilitata ed è fortemente sconsigliato abilitarla; sudo viene utilizzato proprio per evitare di digitare la password di root.

listpw
Controlla la richiesta della password quando un utente esegue il comando:

$ sudo -l
all
la password non viene chiesta solo se tutte le entries che riguardano l'utente contengono il tag NOPASSWD
any
la password non viene chiesta solo se almeno una entries che riguarda l'utente contiene il tag NOPASSWD
always
la password viene sempre chiesta
never
la password non viene mai chiesta. "listpw=never" è equivalente a "!listpw"

Esempio1

Defaults	listpw=any
pippo	ALL = NOPASSWD:/usr/bin/tail /var/log/syslog
pippo	ALL = /usr/bin/tail /var/log/kern.log
$ sudo -l
...
...
User pippo may run the following commands on this host:
    (root) NOPASSWD: /usr/bin/tail /var/log/syslog
    (root) /usr/bin/tail /var/log/kern.log

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

Defaults	listpw=all
pippo	ALL = NOPASSWD:/usr/bin/tail /var/log/syslog
pippo	ALL = /usr/bin/tail /var/log/kern.log
$ sudo -l
[sudo] password for pippo:

Il valore di default per questa opzione è "any". Il valore "always" 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.

verifypw
Identica alla precedente. L'unica differenza è che controlla la password richiesta per il comando:

$ sudo -v

Il valore di default è "all".

EMAIL
mailsub
È il soggetto dell'email che verrà inviata in base ai criteri impostati. Di default è:

* * * SECURITY information for %h * * *

mailto
L'indirizzo di posta a cui verrà inviata l'email. Racchiudere tra doppie virgolette se contiene il carattere @ . Di default l'email viene inviata a root.

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

mailerpath
Il path del programma utilizzato per inviare le email. Di default è "/usr/sbin/sendmail" che, in una installazione di default di Debian, è un link che punta a Exim.

mailerflags
I flag da applicare al programma specificato in mailerpath.
Di default questa variabile è impostata a "-t", cioè fa in modo che il programma di posta possa lavorare con indirizzi locali.

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

Defaults	mail_always

mail_badpass
Viene inviata una email se l'utente inserisce una password sbagliata. Di default è disabilitata. Per attivarla:

Defaults	mail_badpass

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

Defaults	mail_no_host

Esempio:

Defaults  	mail_no_host
pippo	localhost = /usr/bin/tail /var/log/kern.log_host

L'email verrà inviata se l'utente pippo si collegherà da remoto (quindi non su "localhost") e proverà ad eseguire:

$ sudo /usr/bin/tail /var/log/kern.log

mail_no_perms
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. Per abilitarla:

Defaults	mail_no_perms

Esempio:

Defaults	mail_no_perms
pippo	ALL : /usr/bin/tail /var/log/kern.log

Verrà inviata una email se pippo prova a:

$ sudo /usr/bin/tail /var/log/syslog

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

Defaults	mail_no_perms
pluto	ALL : /usr/bin/tail /var/log/kern.log

poiché non si trova nelle entries del file. La prossima opzione abilita questo comportamento.

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

Defaults	!mail_no_user

L'esempio è il contrario dell'esempio precedente:

pippo	ALL : /usr/bin/tail /var/log/kern.log

Verrà inviata una email se pluto prova a:

$ sudo /usr/bin/tail /var/log/kern.log

Ma non se pippo prova ad eseguire il comando:

$ sudo /usr/bin/tail /var/log/syslog

a meno che non sia abilitata "mail_no_perms" .

È opportuno, almeno all'inizio, abilitare tutte queste opzioni:

Defaults	mail_always, mail_badpass, mail_no_host, mail_no_perms

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


Esempi

In questo paragrafo saranno raccolti gli esempi che descrivono come utilizzare sudo per compiti specifici e che possono essere di qualche utilità per l'utente.
Queste operazioni non sono obbligatorie e vanno vagliate e adattate con attenzione alle proprie esigenze per evitare di aprire falle di sicurezza del sistema.

Si ricorda che:

  • Il nome del proprio host può essere ricavato attraverso il comando "hostname"
  • Il path del comando va trovato con "whereis -b comando". Ad esempio:
    $ whereis -b less 
    less: /bin/less /usr/bin/less /usr/bin/X11/less

Modificare file

La modifica di file di sistema (normalmente riservata a root) è sicuramente il compito più diffuso per cui viene utilizzato sudo.
Con questa configurazione utilizzeremo "sudoedit" per la modifica dei file di sistema utilizzando il nostro editor di default.

...
Cmnd_Alias EDITFILE = sudoedit /etc/apt/sources.list, \
                      sudoedit /etc/network/interfaces, \
                      sudoedit /etc/default/apache2

pippo miolocalhost = NOEXEC:EDITFILE
...

In qusto modo all'utente "pippo" sarà concesso modificare i file scelti, utilizzando l'editor di default dal solo host "miolocalhost", previo inserimento della propria password. Il comando sarà:

$ sudoedit /etc/apt/sources.list

o:

$ sudo -e /etc/apt/sources.list

Prestare particolare attenzione ai file scelti: quelli indicati sono soltanto un esempio.

Leggere i file di /var/log/

I file di log di sistema che si trovano nella directory /var/log/ non sono accessibili ad un normale utente ma solo ai membri del gruppo "adm" e, ovviamente, a root.
Questa configurazione consentirà di leggere, attraverso il pager "less", alcuni file di log. Si noti che in questo modo si previene la modifica dei file e, principalmente, si consente la lettura solo per alcuni di essi.
Con il seguente esempio non viene chiesta alcuna password attraverso l'uso del tag "NOPASSWD".

...
Cmnd_Alias LETTURALOG = /bin/less /var/log/messages, \
                        /bin/less /var/log/kern.log, \
                        /bin/less /var/log/syslog

pippo miolocalhost = NOPASSWD:LETTURALOG
...

In questo modo l'utente "pippo" potrà eseguire, esclusivamente dall'host "miolocalhost", i comandi:

$ sudo less /var/log/messages
$ sudo less /var/log/kern.log
$ sudo less /var/log/syslog

per leggere i file "messages", "kern.log" o "syslog".

Un'alternativa è leggere i log con le credenziali del gruppo "adm" (che ha i permessi di sola lettura per questi file) anziché di root:

...
Cmnd_Alias LETTURALOG = /bin/less /var/log/messages, \
                        /bin/less /var/log/kern.log, \
                        /bin/less /var/log/syslog

pippo miolocalhost = (:adm) NOPASSWD:LETTURALOG
...

e utilizzare, ad esempio, il comando:

$ sudo -g adm less /var/log/syslog

Questo secondo metodo può essere molto utile nel caso in cui l'utente a cui vengono concessi i permessi di lettura non si trovi a particolare agio con "less" ma voglia utilizzare un editor. In questo caso è opportuno che l'utente esegua il comando con i permessi del gruppo "adm" e che, quindi, non abbia la possibilità di modificare i file letti.
Un esempio potrebbe essere:

...
Cmnd_Alias LETTURALOG = sudoedit /var/log/messages, \
                        sudoedit /var/log/kern.log, \
                        sudoedit /var/log/syslog

pippo miolocalhost = (:adm) NOPASSWD:NOEXEC:LETTURALOG
...

e il conseguente comando permesso attraverso sudo per leggere, ad esempio, il file /var/log/messages sarà:

$ sudoedit -g adm /var/log/messages

Aggiornare la lista dei pacchetti

L'aggiornamento della lista dei pacchetti con:

# apt-get update

è un compito riservato all'amministratore di sistema ma può essere invocato con relativa sicurezza da un normale utente.

Le seguenti modifiche consentiranno all'utente "pippo" di aggiornare la lista dei pacchetti con apt-get senza inserire alcuna password.

...
Cmnd_Alias AGGIORNAMENTO = /usr/bin/apt-get update

pippo miolocalhost = NOPASSWD:AGGIORNAMENTO
...

L'aggiornamento sarà consentito solo se il comando è eseguito sull'host "miolocalhost" con:

$ sudo apt-get update




Guida scritta da: S3v Swirl-auth40.png Debianized 40%
Estesa da:
Wtf 16:10, 5 mag 2024 (CEST)
Verificata da:
Wtf 16:10, 5 mag 2024 (CEST)

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