Privilegi di amministrazione

Versioni Compatibili

Tutte le versioni supportate di Debian

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.

È altamente sconsigliato accedere al sistema come tale utente per effettuare attività ordinarie, per via dei rischi derivanti dai privilegi associati. Pertanto andrebbe utilizzato 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.

Ovviamente si deve scegliere una buona password per l'amministratore, ancor più se come da default è l'unico metodo di autenticazione previsto, e ne va preservata la riservatezza. Si legga per maggiori informazioni questa guida.

Inoltre si raccomanda di:

non eseguire applicazioni sconosciute come amministratore;
non installare software esterno ad APT, in qualsiasi forma (anche di pacchetto Debian), senza essersi accertati della sua autenticità;
non inserire la password usata per svolgere attività di amministrazione da un account compromesso, non sicuro o non fidato.

Con account 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 amministratore.

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)

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.
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 pulito, ereditando soltanto le variabili d'ambiente $TERM, $COLORTERM, $DISPLAY e $XAUTHORITY. Queste ultime due permettono a root di accedere al server grafico associato all'utente che ha invocato su, se presente e attivo.
Alcune variabili d'ambiente però non sono mai ereditate ($HOME, $SHELL, $USER, $LOGNAME, $PATH e $IFS) ed altre (come $LD_PRELOAD e $LD_DEBUG_OUTPUT) non hanno effetto per ragioni di sicurezza.

Si ricordi sempre comunque che può essere insicuro utilizzare su senza una di queste tre opzioni, con il significato equivalente: -, -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 amministratore.

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 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 effetuare subito dopo il logout, ritornando alla propria console virtuale o comunque a quella utilizzata dal server grafico.

Per esempio, ecco la procedura per passi:

premere Ctrl-Alt-F2 per passare a tty2;
(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-R Sist-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 amministratore, 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.

Senza account root

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.

In presenza di più persone con incarichi di amministrazione è fondamentale, per non dover condividere la stessa password, mentre in presenza di un unico utente è soltanto un modo per doversi ricordare un'unica password.

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.
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 senza password per 15 minuti dall'ultima richiesta.

Per maggiori informazioni si rimanda alla guida: Configurare SUDO per gestire le attività degli amministratori

Eseguibili con setuid

ATTENZIONE
Questa sezione ha solo scopo didattico, ed è trattata per completezza. Non si dovrebbe mai ricorrere a tale permesso soltanto per evitare l'autenticazione, salvo in situazioni in cui non sia possibile fare altrimenti.

Un amministratore non ha mai la necessità di assegnare setuid a un programma!

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.

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, se non si è più che certi di quello che si sta facendo, e rimuoverlo dai comandi di sistema che lo richiedono può ridurre o anche compromettere le funzionalità del sistema.

Si noti che entrambi su e sudo 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.

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.

Guida scritta da: HAL 9000	Debianized 20%
Estesa da:
Verificata da:
Verificare ed estendere la guida \| Cos'è una guida Debianized