Privilegi di amministrazione: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
mNessun oggetto della modifica
mNessun oggetto della modifica
 
(42 versioni intermedie di 3 utenti non mostrate)
Riga 1: Riga 1:
{{Versioni compatibili}}
{{Versioni compatibili}}
== Introduzione ==
== Introduzione ==
I privilegi di amministratore 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 tradizionalmente 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]].


È '''altamente sconsigliato''' accedere al sistema come tale utente per effettuare attività ordinarie. Invece i suoi privilegi andrebbero impiegati esclusivamente per lo stretto necessario a svolgere attività di amministrazione, quali per esempio l'installazione, l'aggiornamento o la rimozione di software tramite [[APT]], o per modificare i file di configurazione del sistema.
{{Box|Nota|In debian l'utente [[Root]] è abilitato in modo predefinito. È comunque possibile non abilitarlo durante l'installazione o disabilitarlo solo in seguito.}}


Ovviamente si deve scegliere una buona password per l'amministratore, considerando che è l'unico metodo di autenticazione previsto di default, e ne va preservata la riservatezza. Si legga per maggiori informazioni [[Password sicure: la base della sicurezza informatica|questa guida]].
Se l'utente <code>root</code> viene disabilitato è possibile garantire ad uno o più utenti la possibilità di acquisire temporaneamente tutti o parte dei privilegi di amministrazione tramite <code>[[sudo]]</code>.
 
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>''': sono richiesti i privilegi di root.
 
Per esempio la seguente notazione:
<pre># apt update</pre>
significa che il comando (<code>apt update</code>) dev'essere eseguito con privilegi di amministrazione.
 
=== Avvertenze ===
L'utente <code>root</code> e più in generale i privilegi di amministratore andrebbero impiegati esclusivamente per compiere sempre e solo le attività che tali privilegi richiedono, come a puro titolo d'esempio:
* l'installazione, l'aggiornamento o la rimozione di software tramite [[APT]];
* la modifica di file di configurazione del sistema.
Diversamente si corre sempre il rischio di modificare e/o cancellare file critici per il funzionamento del sistema.
 
 
{{Warningbox|È universalmente ritenuto pericoloso, pertanto altamente sconsigliato, compiere le normali sessioni di lavoro in qualità di '''root'''.}}
 
Ovviamente si deve scegliere una buona password per l'account utilizzato per l'amministrazione, considerando che è l'unico metodo di autenticazione previsto di default, e ne va preservata la riservatezza. Si legga per maggiori informazioni [[Password sicure: la base della sicurezza informatica|questa guida]].


Inoltre si raccomanda di:
Inoltre si raccomanda di:
# '''non''' eseguire applicazioni sconosciute come amministratore, e rifiutarsi di inserire la password necessaria per ottenerne i privilegi;
# '''non''' eseguire applicazioni sconosciute con privilegi, e rifiutarsi di inserire la password necessaria per ottenerli per attività per cui non sono previsti;
# '''non''' installare software esterno ad [[APT]], in qualsiasi forma (anche di [[pacchetto|pacchetto Debian]]), senza essersi accertati della sua autenticità;
# '''non''' installare software esterno ad [[APT]], in qualsiasi forma (anche di [[pacchetto|pacchetto Debian]]), senza essersi accertati della sua autenticità;
# '''non''' aggiungere [[repository]] non ufficiali senza controllarne l'autenticità e senza averne un reale bisogno, limitandone il numero il più possibile ed evitando assolutamente liste di repository di terze parti;
# '''non''' aggiungere [[repository]] non ufficiali senza controllarne l'autenticità e senza averne un reale bisogno, limitandone il numero il più possibile ed evitando assolutamente liste di repository di terze parti;
# '''non''' inserire la password usata per svolgere attività di amministrazione da un account compromesso, non sicuro o non fidato.
# '''non''' inserire la password usata per svolgere attività di amministrazione da un account compromesso, non sicuro o non fidato.


== Con account ''root'' ==
== Acquisire i privilegi ==
Come anticipato nell'introduzione esistono due modi in linux per acquisire i privilegi di amministrazione:
* usando l'utente <code>root</code>, se abilitato;
* aggiungendo un utente regolare al gruppo <code>sudo</code> che tipicamente garantisce ai suoi membri tutti i privilegi di amministrazione (ma questo aspetto può essere personalizzato).
 
=== L'utente ''root'' ===
Con le impostazioni di default l'account dell'utente '''root''' è abilitato, e la sua password è richiesta per svolgere attività di amministrazione.
Con le impostazioni di default l'account dell'utente '''root''' è abilitato, e la sua password è richiesta per svolgere attività di amministrazione.


È comunque possibile non abilitarlo durante l'installazione, o anche disabilitarlo in seguito. In tal caso '''non''' si possono utilizzare i metodi esposti in questa sezione per ottenere i '''privilegi di amministratore'''.
È comunque possibile non abilitarlo durante l'installazione, o anche disabilitarlo in seguito. In tal caso '''non''' si possono utilizzare i metodi esposti in questa sezione per ottenere i '''privilegi di amministrazione'''.


=== Utilizzo di ''su'' ===
==== Utilizzo di ''su'' ====
Una volta effettuato il login con il proprio utente '''non''' privilegiato, il metodo classico su Debian per poter diventare [[root]], ed avere quindi la possibilità di svolgere operazioni di amministrazione, è quello di eseguire il comando <code>su</code> ('''''S'''witch '''U'''ser''):
Una volta effettuato il login con il proprio utente '''non''' privilegiato, il metodo classico su Debian per poter diventare [[root]], ed avere quindi la possibilità di svolgere operazioni di amministrazione, è quello di eseguire il comando <code>su</code> ('''''S'''witch '''U'''ser''):
<pre>
<pre>
Riga 34: Riga 58:
#
#
</pre>
</pre>
''(che identifica sempre l'utente root)''
''(che identifica sempre l'utente root)''. Inoltre la posizione attuale viene cambiata da quella corrente a <code>/root</code> (facilmente verificabile digitando il comando <code>pwd</code>).


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, con il significato equivalente: <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 48: Riga 71:
oppure ancora più velocemente premere <code>Ctrl-d</code>.
oppure ancora più velocemente premere <code>Ctrl-d</code>.


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 amministratore'''.
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 amministratore. 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 amministratore 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:
Per esempio, ecco la procedura per passi (leggerla '''tutta''' prima di provarla!):
* premere <code>Ctrl-Alt-F2</code> per passare a '''tty2''';
* 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-R Sist-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;  
* digitare i comandi che richiedono privilegi di amministratore, e soltanto quelli ('''non''' usare la [[shell]] per altre attività!);
* digitare i comandi che richiedono privilegi di amministrazione, e soltanto quelli ('''non''' usare la [[shell]] per altre attività!);
* uscire con <code>exit</code> o premendo <code>Ctrl-d</code> per terminare la shell;
* uscire con <code>exit</code> o premendo <code>Ctrl-d</code> per terminare la shell;
* premere <code>Alt-FrecciaSinistra</code> per passare alla console precedente, e ripetere fino a tornare a quella di partenza o eventualmente al proprio server grafico.
* premere <code>Alt-FrecciaSinistra</code> per passare alla console precedente, e ripetere fino a tornare a quella di partenza o eventualmente al proprio server grafico.
Riga 65: Riga 119:
Questo metodo, anche se molto più laborioso degli altri, è l'unico sempre '''sicuro''' anche se l'account dell'utente utilizzato per eseguire <code>su</code> o <code>sudo</code> fosse stato compromesso, perché ha il vantaggio di appoggiarsi unicamente sulla sicurezza del sistema.
Questo metodo, anche se molto più laborioso degli altri, è l'unico sempre '''sicuro''' anche se l'account dell'utente utilizzato per eseguire <code>su</code> o <code>sudo</code> fosse stato compromesso, perché ha il vantaggio di appoggiarsi unicamente sulla sicurezza del sistema.


== Senza account ''root'' ==
=== Utilizzo di ''sudo'' ===
Se durante l'installazione si ha disabilitato l'account '''root''', il primo utente creato è stato automaticamente aggiunto al gruppo '''sudo'''. In tal caso l'unico modo per ottenere '''privilegi di amministratore''' è tramite [[sudo]].
Se durante l'installazione si ha disabilitato l'account '''root''', il primo utente creato è stato automaticamente aggiunto al gruppo '''sudo'''. In tal caso l'unico modo per ottenere '''privilegi di amministrazione''' è tramite [[sudo]].  


In presenza di più persone con incarichi di amministrazione è fondamentale, per non dover condividere la stessa password e permettere il log dei comandi eseguiti da ciascuna, mentre in presenza di un unico utente è soltanto un modo per doversi ricordare un'unica password, salvo modifiche della configurazione di default.
{{Box | Sistemi multiutente | In presenza di più persone con incarichi di amministrazione è fondamentale, per non dover condividere la stessa password e permettere il log dei comandi eseguiti da ciascuna, mentre in presenza di un unico utente è soltanto un modo per doversi ricordare un'unica password, salvo modifiche della configurazione di default.}}
 
=== Utilizzo di ''sudo'' ===
'''Sudo''' può essere usato per eseguire un comando come utente [[root]], tramite la richiesta della password dell'utente che esegue il comando, se ha i permessi necessari.


Solitamente, se installato e configurato, si scrive [[sudo]] prima di ogni comando da eseguire come amministratore. <br/>
Solitamente, se installato e configurato, si scrive [[sudo]] prima di ogni comando da eseguire con privilegi di amministrazione. <br/>
Per esempio:
Per esempio:
<pre>
<pre>
Riga 88: Riga 139:
# exit
# exit
</pre>
</pre>
con la differenza che <code>su</code> chiede la password dell'utente [[root]], il cui account deve essere abilitato, mentre <code>sudo</code> quella dell'utente; e inoltre <code>sudo</code> di default non avvia una shell, riducendo la possibilità di errori accidentali, ma di default permette allo stesso utente l'esecuzione di nuovi comandi senza password per 15 minuti dall'ultima richiesta.
con la differenza che <code>su</code> chiede la password dell'utente [[root]], il cui account deve essere abilitato, mentre <code>sudo</code> quella dell'utente; e inoltre <code>sudo</code> di default non avvia una shell, riducendo la possibilità di errori accidentali, ma di default permette allo stesso utente l'esecuzione di nuovi comandi sulla stessa console o terminale senza password per 15 minuti dall'ultima richiesta.
 
{{Box | Approfondimenti | Per maggiori informazioni si rimanda alle seguenti guide:
* [[Guida a Sudo]]
* [[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 ===
Se si è installato uno degli ambienti desktop oppure direttamente il pacchetto '''policykit-1''', che ne è una dipendenza, si può utilizzare il framework di sicurezza ''polkit'' tramite il comando <code>pkexec</code> (azione: ''org.freedesktop.policykit.exec'').
 
È installato su Debian con diversi profili di default, per permettere in determinate circostanze azioni privilegiate a utenti che non dispongono dei privilegi di amministrazione, come per esempio: spegnimento, riavvio, sospensione e ibernazione del sistema in assenza di altri utenti collegati.
 
Permette anche l'esecuzione di comandi che richiedono privilegi di amministrazione, previa una forma di autenticazione. Se l'account [[root]] è attivo e non si fa parte del gruppo ''sudo'' verrà richiesta la sua password, altrimenti se si fa parte del gruppo ''sudo'' verrà richiesta la password dell'utente corrente, in modo del tutto trasparente dalle scelte effettuate in fase di installazione.
 
L'uso base è molto simile a <code>sudo</code>, nel senso che il comando va scritto prima di ogni comando che si vuole eseguire con privilegi, e infatti:
<pre>
$ pkexec id -u
</pre>
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 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.
 
==== Programmi grafici ====
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>
 
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:
...
<action id="...">
  ...
  <annotate key="org.freedesktop.policykit.exec.path">'''/usr/sbin/synaptic'''</annotate>
  <annotate key="org.freedesktop.policykit.exec.allow_gui">'''true'''</annotate>
  ...
</action>
...
che permetterebbe anche:
<pre>
$ pkexec /usr/sbin/synaptic
</pre>
 
== 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:
<pre># apt update
# apt upgrade</pre>
(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>.
 
{{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'' ===
Si avvia un terminale virtuale o un emulatore di terminale (in ambiente grafico) e si ottengono i privilegi con <code>su</code>:
<pre>$ su -
(richiesta password di root, non stampata a schermo, e INVIO)
# apt update
# apt upgrade
# exit
$</pre>
Si ricorda nuovamente che il carattere finale del prompt riportato ('''<code>$</code>''' oppure '''<code>#</code>''') non si digita.
 
=== 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:
<pre>$ sudo apt update
(richiesta password dell'utente, non stampata a schermo, e INVIO)
$ sudo apt upgrade</pre>
Anche in questo caso il carattere finale del prompt ('''<code>$</code>''') non si digita.
 
Dopo il secondo comando non dovrebbe essere richiesta alcuna password, salvo cambiamenti al valore di default del timeout o se si è atteso troppo tra un comando e il successivo. Inoltre nuovi comandi potranno essere digitati sulla stessa console o terminale con <code>sudo</code> fino allo scadere del timeout, a meno che venga chiusa (premendo <code>Ctrl-d</code>) o sia invalidata con:
<pre>$ sudo -k</pre>
 
=== 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:
<pre>$ pkexec apt update
(richiesta password di root/utente)
$ pkexec apt upgrade
(richiesta password di root/utente)
</pre>


Per maggiori informazioni si rimanda alla guida: [[Configurare SUDO per gestire le attività degli amministratori]]
Fa parte del framework di autenticazione ''polkit'', presente di default in ogni ambiente desktop.


=== Eseguibili con ''setuid'' ===
== 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.
{{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.


Un amministratore non dovrebbe '''mai''' avere la necessità di assegnare ''setuid'' a un programma!}}
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 amministratore''' da chiunque abbia il permesso di esecuzione.
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 maggiori informazioni si rimanda alla guida: [[Filesystem: i permessi sui files]]
Riga 103: Riga 234:
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.
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 entrambi <code>su</code> e <code>sudo</code> per ottenere i privilegi di amministratore 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.
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.


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.
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 sudo</code><br/>
<code>man pkexec</code>


{{Autori
{{Autori
|Autore=[[Utente:HAL 9000|HAL 9000]]
|Autore= [[Utente:HAL 9000|HAL 9000]] 14:14, 21 lug 2019 (CEST)
|Verificata_da=
|Verificata_da=
|Numero_revisori=0
|Numero_revisori=0
|Estesa_da=
|Estesa_da=
}}
}}
[[Categoria:Debian e sicurezza]]
[[Categoria:Debian e sicurezza]]
[[Categoria:Shell]]
[[Categoria:Shell]]
[[Categoria:Monitoraggio]]
[[Categoria:Monitoraggio]]

Versione attuale delle 14:30, 5 mag 2024

Debian-swirl.png Versioni Compatibili

Tutte le versioni supportate di Debian

Introduzione

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.

Info.png Nota
In debian l'utente Root è abilitato in modo predefinito. È comunque possibile non abilitarlo durante l'installazione o disabilitarlo solo in seguito.


Se l'utente root viene disabilitato è possibile garantire ad uno o più utenti la possibilità di acquisire temporaneamente tutti o parte dei privilegi di amministrazione tramite sudo.

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:

  • $: il comando che segue è utilizzabile da tutti gli utenti;
  • #: sono richiesti i privilegi di root.

Per esempio la seguente notazione:

# apt update

significa che il comando (apt update) dev'essere eseguito con privilegi di amministrazione.

Avvertenze

L'utente root e più in generale i privilegi di amministratore andrebbero impiegati esclusivamente per compiere sempre e solo le attività che tali privilegi richiedono, come a puro titolo d'esempio:

  • l'installazione, l'aggiornamento o la rimozione di software tramite APT;
  • la modifica di file di configurazione del sistema.

Diversamente si corre sempre il rischio di modificare e/o cancellare file critici per il funzionamento del sistema.


Warning.png ATTENZIONE
È universalmente ritenuto pericoloso, pertanto altamente sconsigliato, compiere le normali sessioni di lavoro in qualità di root.


Ovviamente si deve scegliere una buona password per l'account utilizzato per l'amministrazione, considerando che è l'unico metodo di autenticazione previsto di default, e ne va preservata la riservatezza. Si legga per maggiori informazioni questa guida.

Inoltre si raccomanda di:

  1. non eseguire applicazioni sconosciute con privilegi, e rifiutarsi di inserire la password necessaria per ottenerli per attività per cui non sono previsti;
  2. non installare software esterno ad APT, in qualsiasi forma (anche di pacchetto Debian), senza essersi accertati della sua autenticità;
  3. non aggiungere repository non ufficiali senza controllarne l'autenticità e senza averne un reale bisogno, limitandone il numero il più possibile ed evitando assolutamente liste di repository di terze parti;
  4. non inserire la password usata per svolgere attività di amministrazione da un account compromesso, non sicuro o non fidato.

Acquisire i privilegi

Come anticipato nell'introduzione esistono due modi in linux per acquisire i privilegi di amministrazione:

  • usando l'utente root, se abilitato;
  • aggiungendo un utente regolare al gruppo sudo che tipicamente garantisce ai suoi membri tutti i privilegi di amministrazione (ma questo aspetto può essere personalizzato).

L'utente root

Con le impostazioni di default l'account dell'utente root è abilitato, e la sua password è richiesta per svolgere attività di amministrazione.

È comunque possibile non abilitarlo durante l'installazione, o anche disabilitarlo in seguito. In tal caso non si possono utilizzare i metodi esposti in questa sezione per ottenere i privilegi di amministrazione.

Utilizzo di su

Una volta effettuato il login con il proprio utente non privilegiato, il metodo classico su Debian per poter diventare root, ed avere quindi la possibilità di svolgere operazioni di amministrazione, è quello di eseguire il comando su (Switch User):

su -

Verrà richiesta la password di root e sarà eseguito l’accesso.

Noterete che il prompt della shell è cambiato, passando da:

$

(che identifica un utente normale) (alcune shell, come zsh, potrebbero utilizzare il simbolo % al posto di $)
a:

#

(che identifica sempre l'utente root). Inoltre la posizione attuale viene cambiata da quella corrente a /root (facilmente verificabile digitando il comando pwd).

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.
L'opzione - (trattino, oppure nelle forme -l e --login) dopo il comando su serve appunto ad avviare una shell di login, che utilizza un ambiente il più possibile pulito.

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

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:

exit

oppure ancora più velocemente premere Ctrl-d.

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 $TERM, $COLORTERM, $DISPLAY e $XAUTHORITY. Queste ultime due permettono a root di accedere al server grafico (via Xorg) associato all'utente che ha invocato su, se presente e attivo.

Si noti che a partire da Debian 10 (Buster) soltanto $TERM viene ereditata. Pertanto per lanciare un'applicazione grafica (via Xorg) da terminale come root, è necessario specificare esplicitamente $DISPLAY e $XAUTHORITY ai loro valori precedenti:

$ echo $DISPLAY
:0
$ echo $XAUTHORITY
/home/utente/.Xauthority

# su -
# DISPLAY=:0 XAUTHORITY=/home/utente/.Xauthority synaptic
# exit
$

È invece rimasto invariato il comportamento di su senza shell di login, per quanto sia sconsigliabile, visto che sarebbero ereditate anche tutte le variabili d'ambiente (si noti infatti che $PATH non è cambiata, e pertanto non conterrà le directory /sbin e /usr/sbin, rendendo necessario specificare il percorso completo di un eseguibile che si trovi in tali directory):

$ su -c /usr/sbin/synaptic
$
$ su
# /usr/sbin/synaptic
# exit
$

Alcune variabili d'ambiente non sono mai ereditate in ogni caso ($HOME, $SHELL, $USER, $LOGNAME, $PATH e $IFS) ed altre (come $LD_PRELOAD e $LD_DEBUG_OUTPUT) non hanno effetto per ragioni di sicurezza.

Prima di Debian 10 (Buster) su modificava la variable $PATH anche quando non era avviata una shell di login, per quanto il suo uso (senza una delle opzioni - / -l / --login) fosse comunque sconsigliato nella maggior parte dei casi.

Login diretto come root

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 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!):

  • premere Ctrl-Alt-F2 per passare a tty2 (oppure Ctrl-Alt-F3 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 Alt-RSist-k (oppure Alt-Stamp-k) per generare una nuova console sicura, terminando tutte le eventuali applicazioni collegate;
  • effettuare il login con root e la password corrispondente;
  • digitare i comandi che richiedono privilegi di amministrazione, e soltanto quelli (non usare la shell per altre attività!);
  • uscire con exit o premendo Ctrl-d per terminare la shell;
  • premere Alt-FrecciaSinistra per passare alla console precedente, e ripetere fino a tornare a quella di partenza o eventualmente al proprio server grafico.

Questo metodo, anche se molto più laborioso degli altri, è l'unico sempre sicuro anche se l'account dell'utente utilizzato per eseguire su o sudo fosse stato compromesso, perché ha il vantaggio di appoggiarsi unicamente sulla sicurezza del sistema.

Utilizzo di sudo

Se durante l'installazione si ha disabilitato l'account root, il primo utente creato è stato automaticamente aggiunto al gruppo sudo. In tal caso l'unico modo per ottenere privilegi di amministrazione è tramite sudo.

Info.png Sistemi multiutente
In presenza di più persone con incarichi di amministrazione è fondamentale, per non dover condividere la stessa password e permettere il log dei comandi eseguiti da ciascuna, mentre in presenza di un unico utente è soltanto un modo per doversi ricordare un'unica password, salvo modifiche della configurazione di default.


Solitamente, se installato e configurato, si scrive sudo prima di ogni comando da eseguire con privilegi di amministrazione.
Per esempio:

$ id -u

restituisce l'UID del proprio utente, che sarà maggiore di 0 (su Debian di default è maggiore o uguale a 1000), ma:

$ sudo id -u

dopo la richiesta della propria password restituisce 0 (l'UID di root) ed è quasi equivalente a:

$ su -
# id -u
# exit

con la differenza che su chiede la password dell'utente root, il cui account deve essere abilitato, mentre sudo quella dell'utente; e inoltre sudo di default non avvia una shell, riducendo la possibilità di errori accidentali, ma di default permette allo stesso utente l'esecuzione di nuovi comandi sulla stessa console o terminale senza password per 15 minuti dall'ultima richiesta.

Info.png Approfondimenti
Per maggiori informazioni si rimanda alle seguenti guide:


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

Se si è installato uno degli ambienti desktop oppure direttamente il pacchetto policykit-1, che ne è una dipendenza, si può utilizzare il framework di sicurezza polkit tramite il comando pkexec (azione: org.freedesktop.policykit.exec).

È installato su Debian con diversi profili di default, per permettere in determinate circostanze azioni privilegiate a utenti che non dispongono dei privilegi di amministrazione, come per esempio: spegnimento, riavvio, sospensione e ibernazione del sistema in assenza di altri utenti collegati.

Permette anche l'esecuzione di comandi che richiedono privilegi di amministrazione, previa una forma di autenticazione. Se l'account root è attivo e non si fa parte del gruppo sudo verrà richiesta la sua password, altrimenti se si fa parte del gruppo sudo verrà richiesta la password dell'utente corrente, in modo del tutto trasparente dalle scelte effettuate in fase di installazione.

L'uso base è molto simile a sudo, nel senso che il comando va scritto prima di ogni comando che si vuole eseguire con privilegi, e infatti:

$ pkexec id -u

restituisce 0, ossia l'UID di root, dopo aver richiesto la password necessaria per ottenere i privilegi.

Rispetto a su e sudo però, pkexec 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.

Programmi grafici

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 synaptic c'è synaptic-pkexec:

$ synaptic-pkexec

Normalmente $DISPLAY e $XAUTHORITY non sono ereditate, ma è possibile specificare diversamente in /usr/share/polkit-1/actions/. Per esempio /usr/share/polkit-1/actions/com.ubuntu.pkexec.synaptic.policy contiene:

...
<action id="...">
 ...
 <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/synaptic</annotate>
 <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
 ...
</action>
...

che permetterebbe anche:

$ pkexec /usr/sbin/synaptic

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:

# apt update
# apt upgrade

(Si legga per maggiori informazioni: Introduzione all'APT System)

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

Info.png 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 # e basterà quindi digitare i due comandi e poi uscire dalla console (premendo Ctrl-d.)


Con account root attivo e su

Si avvia un terminale virtuale o un emulatore di terminale (in ambiente grafico) e si ottengono i privilegi con su:

$ su -
(richiesta password di root, non stampata a schermo, e INVIO)
# apt update
# apt upgrade
# exit
$

Si ricorda nuovamente che il carattere finale del prompt riportato ($ oppure #) non si digita.

Senza account root attivo e sudo

Se non si è abilitato l'account root, si disporrà del comando sudo, di default attivato per il primo utente creato. Il carattere finale del prompt resterà sempre $, e anziché avviare una shell privilegiata è consigliabile utilizzare sudo prima di ogni comando:

$ sudo apt update
(richiesta password dell'utente, non stampata a schermo, e INVIO)
$ sudo apt upgrade

Anche in questo caso il carattere finale del prompt ($) non si digita.

Dopo il secondo comando non dovrebbe essere richiesta alcuna password, salvo cambiamenti al valore di default del timeout o se si è atteso troppo tra un comando e il successivo. Inoltre nuovi comandi potranno essere digitati sulla stessa console o terminale con sudo fino allo scadere del timeout, a meno che venga chiusa (premendo Ctrl-d) o sia invalidata con:

$ sudo -k

Con pkexec

Come per sudo il carattere finale del prompt rimarrà sempre $, e in maniera analoga si scriverà pkexec prima di ogni comando da eseguire con privilegi:

$ pkexec apt update
(richiesta password di root/utente)
$ pkexec apt upgrade
(richiesta password di root/utente)

Fa parte del framework di autenticazione polkit, presente di default in ogni ambiente desktop.

Approfondimento: eseguibili setuid

Warning.png ATTENZIONE
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 su, sudo e pkexec 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

man su
man sudo
man pkexec




Guida scritta da: HAL 9000 14:14, 21 lug 2019 (CEST) Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

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