Privilegi di amministrazione: differenze tra le versioni

Vai alla navigazione Vai alla ricerca
m
(6 versioni intermedie di 2 utenti non mostrate)
Riga 3: Riga 3:
I privilegi di amministrazione (detti anche ''privilegi di root'') permettono di svolgere qualsiasi operazione, dall'alterazione e la cancellazione di qualsiasi file al controllo di tutte le risorse del sistema. E su sistemi operativi Unix e Unix-like, come lo è GNU/Linux Debian, questi privilegi sono assegnati all'utente con [[UID]] pari a '''0''', ossia all'utente [[root]].
I privilegi di amministrazione (detti anche ''privilegi di root'') permettono di svolgere qualsiasi operazione, dall'alterazione e la cancellazione di qualsiasi file al controllo di tutte le risorse del sistema. E su sistemi operativi Unix e Unix-like, come lo è GNU/Linux Debian, questi privilegi sono assegnati all'utente con [[UID]] pari a '''0''', ossia all'utente [[root]].


In tutta questa Wiki, e tradizionalmente per Debian e la maggior parte delle distribuzioni GNU/Linux, si utilizza il carattere di prompt (che non va digitato, ed è già presente nel terminale o nella console virtuale utilizzata) per indicare quali comandi vanno eseguiti con privilegi:
In tutta questa Wiki, e tradizionalmente per Debian e la maggior parte delle distribuzioni GNU/Linux, si utilizza il carattere di prompt (che non va digitato, ed è già presente nel terminale virtuale o nell'emulatore di terminale) per indicare quali comandi vanno eseguiti con privilegi:
* '''<code>$</code>''': il comando che segue è utilizzabile da tutti gli utenti;
* '''<code>$</code>''': il comando che segue è utilizzabile da tutti gli utenti;
* '''<code>#</code>''': sono richiesti i privilegi di root.
* '''<code>#</code>''': sono richiesti i privilegi di root.


Per esempio:
Per esempio:
<pre># apt-get update</pre>
<pre># apt update</pre>
significa che il comando (<code>apt-get update</code>) dev'essere eseguito con privilegi di amministrazione.
significa che il comando (<code>apt update</code>) dev'essere eseguito con privilegi di amministrazione.


== Avvertenze ==
== Avvertenze ==
Riga 47: Riga 47:
''(che identifica sempre l'utente root)''
''(che identifica sempre l'utente root)''


Per essere precisi è stata avviata una nuova [[shell]] di login, e le è stato assegnato il controllo della console virtuale o del terminale (all'interno di una sessione grafica) utilizzato.<br/>
Per essere precisi è stata avviata una nuova [[shell]] di login, e le è stato assegnato il controllo del terminale virtuale o dell'emulatore di terminale (all'interno di una sessione grafica) utilizzato.<br/>
L'opzione <code>-</code> (''trattino'', oppure nelle forme <code>-l</code> e <code>--login</code>) dopo il comando <code>su</code> serve appunto ad avviare una shell di login, che utilizza un ambiente pulito, ereditando soltanto le variabili d'ambiente <code>$TERM</code>, <code>$COLORTERM</code>, <code>$DISPLAY</code> e <code>$XAUTHORITY</code>. Queste ultime due permettono a [[root]] di accedere al server grafico associato all'utente che ha invocato <code>su</code>, se presente e attivo.<br/>
L'opzione <code>-</code> (''trattino'', oppure nelle forme <code>-l</code> e <code>--login</code>) dopo il comando <code>su</code> serve appunto ad avviare una shell di login, che utilizza un ambiente il più possibile pulito.
Alcune variabili d'ambiente però non sono mai ereditate (<code>$HOME</code>, <code>$SHELL</code>, <code>$USER</code>, <code>$LOGNAME</code>, <code>$PATH</code> e <code>$IFS</code>) ed altre (come <code>$LD_PRELOAD</code> e <code>$LD_DEBUG_OUTPUT</code>) non hanno effetto per ragioni di sicurezza.


Si ricordi sempre comunque che può essere '''insicuro''' utilizzare <code>su</code> senza una di queste tre opzioni, equivalenti, che proteggono da possibili errori accidentali causati da un ambiente non pulito: <code>-</code>, <code>-l</code>, <code>--login</code> .
Si ricordi sempre infatti che può essere '''insicuro''' utilizzare <code>su</code> senza una di queste tre opzioni, equivalenti, che proteggono da possibili errori accidentali causati da un ambiente non pulito: <code>-</code>, <code>-l</code>, <code>--login</code> .


Per ritornare utenti normali è necessario terminare la shell, così che il controllo ritorni a quella che si utilizzava precedentemente, con i soli privilegi di utente. Quindi basta digitare il comando:
Per ritornare utenti normali è necessario terminare la shell, così che il controllo ritorni a quella che si utilizzava precedentemente, con i soli privilegi di utente. Quindi basta digitare il comando:
Riga 60: Riga 59:


Nei comandi riportati in tutta questa Wiki, e in generale nella documentazione di tutti i sistemi Unix, il prompt è riportato prima di ogni comando da digitare per indicare se richiede o meno i privilegi di amministrazione.
Nei comandi riportati in tutta questa Wiki, e in generale nella documentazione di tutti i sistemi Unix, il prompt è riportato prima di ogni comando da digitare per indicare se richiede o meno i privilegi di amministrazione.
===== Variabili d'ambiente e programmi grafici =====
Con una nuova shell di login, sono ereditate soltanto le variabili d'ambiente <code>$TERM</code>, <code>$COLORTERM</code>, <code>$DISPLAY</code> e <code>$XAUTHORITY</code>. Queste ultime due permettono a [[root]] di accedere al server grafico (via Xorg) associato all'utente che ha invocato <code>su</code>, se presente e attivo.
Si noti che a partire da Debian 10 ([[Buster]]) soltanto <code>$TERM</code> viene ereditata. Pertanto per lanciare un'applicazione grafica (via Xorg) da terminale come root, è necessario specificare esplicitamente <code>$DISPLAY</code> e <code>$XAUTHORITY</code> ai loro valori precedenti:
<pre>
$ echo $DISPLAY
:0
$ echo $XAUTHORITY
/home/utente/.Xauthority
# su -
# DISPLAY=:0 XAUTHORITY=/home/utente/.Xauthority synaptic
# exit
$
</pre>
È invece rimasto invariato il comportamento di <code>su</code> senza shell di login, per quanto sia sconsigliabile, visto che sarebbero ereditate anche tutte le variabili d'ambiente (si noti infatti che <code>$PATH</code> non è cambiata, e pertanto non conterrà le directory <code>/sbin</code> e <code>/usr/sbin</code>, rendendo necessario specificare il percorso completo di un eseguibile che si trovi in tali directory):
<pre>
$ su -c /usr/sbin/synaptic
$
</pre>
<pre>
$ su
# /usr/sbin/synaptic
# exit
$
</pre>
Alcune variabili d'ambiente non sono mai ereditate in ogni caso (<code>$HOME</code>, <code>$SHELL</code>, <code>$USER</code>, <code>$LOGNAME</code>, <code>$PATH</code> e <code>$IFS</code>) ed altre (come <code>$LD_PRELOAD</code> e <code>$LD_DEBUG_OUTPUT</code>) non hanno effetto per ragioni di sicurezza.
Prima di Debian 10 ([[Buster]]) <code>su</code> modificava la variable <code>$PATH</code> anche quando non era avviata una shell di login, per quanto il suo uso (senza una delle opzioni <code>-</code> / <code>-l</code> / <code>--login</code>) fosse comunque sconsigliato nella maggior parte dei casi.


==== Login diretto come ''root'' ====
==== Login diretto come ''root'' ====
Un'altra possibilità è effettuare direttamente un login come [[root]], solo per lo stretto necessario a svolgere l'attività di amministrazione.
Un'altra possibilità è effettuare direttamente un login come [[root]], solo per lo stretto necessario a svolgere l'attività di amministrazione.


È '''sconsigliato''' effettuare un login da interfaccia grafica, per via dell'elevato numero di applicazioni che riceverebbero i privilegi di amministrazione. Si può invece passare a una console virtuale non utilizzata (per esempio '''/dev/tty2'''), effettuare il login come '''root''', eseguire i soli comandi per cui sono necessari i privilegi di amministrazione e poi effettuare subito dopo il logout, ritornando alla propria console virtuale o comunque a quella utilizzata dal server grafico.
È '''sconsigliato''' effettuare un login da interfaccia grafica, per via dell'elevato numero di applicazioni che riceverebbero i privilegi di amministrazione. Si può invece passare a un terminale virtuale non utilizzato (per esempio '''/dev/tty2'''), effettuare il login come '''root''', eseguire i soli comandi per cui sono necessari i privilegi di amministrazione e poi effettuare subito dopo il logout, ritornando al proprio terminale virtuale o comunque a quello utilizzato dal server grafico.


Per esempio, ecco la procedura per passi (leggerla '''tutta''' prima di provarla!):
Per esempio, ecco la procedura per passi (leggerla '''tutta''' prima di provarla!):
* premere <code>Ctrl-Alt-F2</code> per passare a '''tty2''' (oppure <code>Ctrl-Alt-F3</code> per '''tty3''', ecc... ; basta che la console virtuale sia libera);
* premere <code>Ctrl-Alt-F2</code> per passare a '''tty2''' (oppure <code>Ctrl-Alt-F3</code> per '''tty3''', ecc... ; basta che il terminale virtuale sia libero);
* (in presenza di più persone con accesso al sistema, o se la console '''tty2''' è stata usata in precedenza) inviare la combinazione '''SysRq+K''' premendo <code>Alt-RSist-k</code> (oppure <code>Alt-Stamp-k</code>) per generare una nuova console sicura, terminando tutte le eventuali applicazioni collegate;
* (in presenza di più persone con accesso al sistema, o se la console '''tty2''' è stata usata in precedenza) inviare la combinazione '''SysRq+K''' premendo <code>Alt-RSist-k</code> (oppure <code>Alt-Stamp-k</code>) per generare una nuova console sicura, terminando tutte le eventuali applicazioni collegate;
* effettuare il login con '''root''' e la password corrispondente;  
* effettuare il login con '''root''' e la password corrispondente;  
Riga 99: Riga 129:


Per maggiori informazioni si rimanda alla guida: [[Configurare SUDO per gestire le attività degli amministratori]]
Per maggiori informazioni si rimanda alla guida: [[Configurare SUDO per gestire le attività degli amministratori]]
==== Programmi grafici ====
Di default si possono già lanciare applicazioni grafiche con root su un server grafico attivo, ma non come altro utente.


=== Utilizzo di ''pkexec'' con polkit ===
=== Utilizzo di ''pkexec'' con polkit ===
Riga 113: Riga 146:
restituisce '''0''', ossia l'[[UID]] di [[root]], dopo aver richiesto la password necessaria per ottenere i privilegi.
restituisce '''0''', ossia l'[[UID]] di [[root]], dopo aver richiesto la password necessaria per ottenere i privilegi.


Rispetto a <code>su</code> e <code>sudo</code> però, <code>pkexec</code> mostra sempre il comando per cui sono richiesti i privilegi assieme alla richiesta di password, sia in presenza di interfaccia grafica che da console virtuale. Si noti che, salvo personalizzazione dei file di configurazione di ''polkit'', di default è richiesto che l'account root sia attivo oppure che si appartenga al gruppo ''sudo'', altrimenti sarà impossibile essere autenticati.
Rispetto a <code>su</code> e <code>sudo</code> però, <code>pkexec</code> mostra sempre il comando per cui sono richiesti i privilegi assieme alla richiesta di password, sia in presenza di interfaccia grafica che da terminale virtuale. Si noti che, salvo personalizzazione dei file di configurazione di ''polkit'', di default è richiesto che l'account root sia attivo oppure che si appartenga al gruppo ''sudo'', altrimenti sarà impossibile essere autenticati.


=== Eseguibili con ''setuid'' ===
==== Programmi grafici ====
{{Warningbox | Questa sezione ha solo scopo didattico, ed è trattata per completezza. Non si dovrebbe '''mai''' ricorrere a tale permesso soltanto per evitare l'autenticazione di un proprio eseguibile, se non si è più che certi di quello che si sta facendo e non è possibile fare altrimenti.
Per alcuni programmi grafici per cui è necessaria l'autenticazione come root sono disponibili dei wrapper che ne permettono l'uso anche da terminale come utente non privilegiato, rimandando l'autenticazione a una finestra grafica. Per esempio per <code>synaptic</code> c<code>synaptic-pkexec</code>:
<pre>
$ synaptic-pkexec
</pre>


Chi si occupa dell'amministrazione non dovrebbe '''mai''' avere la necessità di assegnare ''setuid'' a un programma! È un compito che spetta soltanto a uno sviluppatore, e soltanto in seguito a un'attenta analisi sulle implicazioni sulla sicurezza.}}
Normalmente <code>$DISPLAY</code> e <code>$XAUTHORITY</code> non sono ereditate, ma è possibile specificare diversamente in <code>/usr/share/polkit-1/actions/</code>. Per esempio <code>/usr/share/polkit-1/actions/com.ubuntu.pkexec.synaptic.policy</code> contiene:
 
...
Un eseguibile con tale permesso abilitato, anziché ereditare i privilegi dell'utente che lo avvia, è eseguito con quelli del suo proprietario, '''senza nessuna richiesta di autenticazione'''. Ne consegue che un programma appartenente a [[root]] con ''setuid'' è sempre eseguito con '''privilegi di amministrazione''' da chiunque abbia il permesso di esecuzione.
<action id="...">
 
  ...
Per maggiori informazioni si rimanda alla guida: [[Filesystem: i permessi sui files]]
  <annotate key="org.freedesktop.policykit.exec.path">'''/usr/sbin/synaptic'''</annotate>
 
  <annotate key="org.freedesktop.policykit.exec.allow_gui">'''true'''</annotate>
Per ovvie ragioni '''è estremamente pericoloso''' aggiungere tale permesso a eseguibili che ne sono sprovvisti, e rimuoverlo dai comandi di sistema che lo richiedono può ridurre o anche compromettere le funzionalità del sistema.
  ...
 
</action>
Si noti che <code>su</code>, <code>sudo</code> e <code>pkexec</code> per concedere i privilegi di amministrazione fanno uso di questo permesso, senza il quale non potrebbero funzionare per i normali utenti. E sono stati creati proprio per permettere ad altri programmi di essere eseguiti con privilegi, tramite una forma di autenticazione, in modo controllato e sicuro.
...
 
che permetterebbe anche:
Inoltre, per ragioni di sicurezza, il permesso ''setuid'' è ignorato sugli script. E tutte le unità rimovibili, se montate da un utente normale, di default possono esserlo soltanto con il flag '''nosuid''' attivo, che renderebbe il permesso ''setuid'' privo di efficacia.
<pre>
$ pkexec /usr/sbin/synaptic
</pre>


== Esempio: aggiornamento periodico del sistema ==
== Esempio: aggiornamento periodico del sistema ==
Per effettuare l'aggiornamento periodico del sistema su una Debian [[stable]], i comandi da digitare in una console virtuale o un emulatore di terminale con '''privilegi di amministrazione''' sono:
Per effettuare l'aggiornamento periodico del sistema su una Debian [[stable]], i comandi da digitare in un terminale virtuale o in un emulatore di terminale con '''privilegi di amministrazione''' sono:
<pre># apt-get update
<pre># apt update
# apt-get upgrade</pre>
# apt upgrade</pre>
(Si legga per maggiori informazioni: [[Introduzione all' Apt System]])
(Si legga per maggiori informazioni: [[Introduzione all'APT System]])


Nelle sezioni successive è mostrato brevemente come eseguire questi comandi in modo privilegiato con <code>su</code>, <code>sudo</code> e <code>pkexec</code>.
Nelle sezioni successive è mostrato brevemente come eseguire questi comandi in modo privilegiato con <code>su</code>, <code>sudo</code> e <code>pkexec</code>.


{{Box | Login diretto come root | Si noti che effettuando un login diretto come [[root]] su una console virtuale, ovviamente possibile solo con account root attivo, il carattere finale del prompt sarà sempre '''<code>#</code>''' e basterà quindi digitare i due comandi e poi uscire dalla console (premendo <code>Ctrl-d</code>.)}}
{{Box | Login diretto come root | Si noti che effettuando un login diretto come [[root]] su un terminale virtuale, ovviamente possibile solo con account root attivo, il carattere finale del prompt sarà sempre '''<code>#</code>''' e basterà quindi digitare i due comandi e poi uscire dalla console (premendo <code>Ctrl-d</code>.)}}


=== Con account root attivo e ''su'' ===
=== Con account root attivo e ''su'' ===
Si avvia una console virtuale o un emulatore di terminale (in ambiente grafico) e si ottengono i privilegi con <code>su</code>:
Si avvia un terminale virtuale o un emulatore di terminale (in ambiente grafico) e si ottengono i privilegi con <code>su</code>:
<pre>$ su -
<pre>$ su -
(richiesta password di root, non stampata a schermo, e INVIO)
(richiesta password di root, non stampata a schermo, e INVIO)
# apt-get update
# apt update
# apt-get upgrade
# apt upgrade
# exit
# exit
$</pre>
$</pre>
Riga 152: Riga 190:
=== Senza account root attivo e ''sudo'' ===
=== Senza account root attivo e ''sudo'' ===
Se non si è abilitato l'account root, si disporrà del comando <code>sudo</code>, di default attivato per il primo utente creato. Il carattere finale del prompt resterà sempre '''<code>$</code>''', e anziché avviare una shell privilegiata è consigliabile utilizzare <code>sudo</code> prima di ogni comando:
Se non si è abilitato l'account root, si disporrà del comando <code>sudo</code>, di default attivato per il primo utente creato. Il carattere finale del prompt resterà sempre '''<code>$</code>''', e anziché avviare una shell privilegiata è consigliabile utilizzare <code>sudo</code> prima di ogni comando:
<pre>$ sudo apt-get update
<pre>$ sudo apt update
(richiesta password dell'utente, non stampata a schermo, e INVIO)
(richiesta password dell'utente, non stampata a schermo, e INVIO)
$ sudo apt-get upgrade</pre>
$ sudo apt upgrade</pre>
Anche in questo caso il carattere finale del prompt ('''<code>$</code>''') non si digita.
Anche in questo caso il carattere finale del prompt ('''<code>$</code>''') non si digita.


Riga 161: Riga 199:


=== Con ''pkexec'' ===
=== Con ''pkexec'' ===
Se si è abilitato l'account root, verrà richiesta la sua password, altrimenti verrà richiesta la propria (se si fa parte del gruppo ''sudo''). In entrambi i casi come per <code>sudo</code> il carattere finale del prompt rimarrà sempre '''<code>$</code>''', e si scriverà il comando <code>pkexec</code> prima di ogni comando da eseguire con privilegi:
Come per <code>sudo</code> il carattere finale del prompt rimarrà sempre '''<code>$</code>''', e in maniera analoga si scriverà <code>pkexec</code> prima di ogni comando da eseguire con privilegi:
<pre>$ pkexec apt-get update
<pre>$ pkexec apt update
(richiesta password di root/utente)
(richiesta password di root/utente)
$ pkexec apt-get upgrade
$ pkexec apt upgrade
(richiesta password di root/utente)
(richiesta password di root/utente)
</pre>
</pre>
Riga 170: Riga 208:
Fa parte del framework di autenticazione ''polkit'', presente di default in ogni ambiente desktop.
Fa parte del framework di autenticazione ''polkit'', presente di default in ogni ambiente desktop.


== Approfondimento ==
== Approfondimento: eseguibili ''setuid'' ==
{{Warningbox | Questa sezione ha solo scopo didattico, ed è trattata per completezza. Non si dovrebbe '''mai''' ricorrere a tale permesso soltanto per evitare l'autenticazione di un proprio eseguibile, se non si è più che certi di quello che si sta facendo e non è possibile fare altrimenti.
 
Chi si occupa dell'amministrazione non dovrebbe '''mai''' avere la necessità di assegnare ''setuid'' a un programma! È un compito che spetta soltanto a uno sviluppatore, e soltanto in seguito a un'attenta analisi sulle implicazioni sulla sicurezza.}}
 
Un eseguibile con tale permesso abilitato, anziché ereditare i privilegi dell'utente che lo avvia, è eseguito con quelli del suo proprietario, '''senza nessuna richiesta di autenticazione'''. Ne consegue che un programma appartenente a [[root]] con ''setuid'' è sempre eseguito con '''privilegi di amministrazione''' da chiunque abbia il permesso di esecuzione.
 
Per maggiori informazioni si rimanda alla guida: [[Filesystem: i permessi sui files]]
 
Per ovvie ragioni '''è estremamente pericoloso''' aggiungere tale permesso a eseguibili che ne sono sprovvisti, e rimuoverlo dai comandi di sistema che lo richiedono può ridurre o anche compromettere le funzionalità del sistema.
 
Si noti che <code>su</code>, <code>sudo</code> e <code>pkexec</code> per concedere i privilegi di amministrazione fanno uso di questo permesso, senza il quale non potrebbero funzionare per i normali utenti. E sono stati creati proprio per permettere ad altri programmi di essere eseguiti con privilegi, tramite una forma di autenticazione, in modo controllato e sicuro.
 
Inoltre, per ragioni di sicurezza, il permesso ''setuid'' è ignorato sugli script. E tutte le unità rimovibili, se montate da un utente normale, di default possono esserlo soltanto con il flag '''nosuid''' attivo, che renderebbe il permesso ''setuid'' privo di efficacia.
 
== Approfondimenti ==
<code>man su</code><br/>
<code>man su</code><br/>
<code>man sudo</code><br/>
<code>man sudo</code><br/>
Riga 176: Riga 229:


{{Autori
{{Autori
|Autore= [[Utente:HAL 9000|HAL 9000]] 20:41, 24 apr 2015 (CEST)
|Autore= [[Utente:HAL 9000|HAL 9000]] 14:14, 21 lug 2019 (CEST)
|Verificata_da=
|Verificata_da=
|Numero_revisori=0
|Numero_revisori=0
3 581

contributi

Menu di navigazione