Guide@Debianizzati.Org

Privilegi di amministrazione: differenze tra le versioni

Pagina Discussione

Privilegi di amministrazione (visualizza wikitesto)

Versione delle 12:14, 21 lug 2019

2 128 byte aggiunti ,  21 lug 2019
verifica, aggiornamento per cambiamenti al default di "su --login/su -l/su -", applicazioni grafiche
mNessun oggetto della modifica
(verifica, aggiornamento per cambiamenti al default di "su --login/su -l/su -", applicazioni grafiche)
Riga 48: Riga 48:


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


==== Login diretto come ''root'' ====
==== Login diretto come ''root'' ====
Riga 99: Riga 127:


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 115: Riga 146:
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.
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 un terminale virtuale o in 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]])


Riga 144: Riga 180:
<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 188:
=== 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 162: Riga 198:
=== Con ''pkexec'' ===
=== Con ''pkexec'' ===
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:
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 206:
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 227:


{{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
HAL 9000
3 581

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/43020"