- L'accesso come root offre il controllo completo, ma Ubuntu e altre distribuzioni lo mantengono disabilitato per impostazione predefinita per ridurre i rischi.
- Sudo consente di elevare i privilegi caso per caso e tiene traccia di chi esegue ciascun comando.
- Per le applicazioni grafiche, esistono programmi di supporto come kdesu, gksu, gksudo o pkexec, che possono essere utilizzati nei launcher .desktop.
- La sicurezza si basa sull'utilizzo del principio del minimo privilegio, sull'evitare script non attendibili e sul monitoraggio degli accessi con privilegi elevati.
In Windows, molti utenti sono abituati a premere Maiusc+Invio o Maiusc+clic sinistro per aprire un programma con privilegi elevati dal menu Start. In Linux, la procedura non è sempre così semplice, poiché la sicurezza si basa su root, sudo e strumenti grafici , e ogni ambiente desktop ha i propri strumenti. Ciononostante, esistono metodi piuttosto semplici per avviare applicazioni come root da un launcher, un collegamento o dal menu Applicazioni, sebbene sia importante comprenderne le implicazioni.
Il punto chiave è che l'utente root ha il controllo assoluto del sistema e le distribuzioni moderne, in particolare Ubuntu e i suoi derivati, in genere disabilitano l'accesso diretto. Pertanto, non è comune accedere come root, ma piuttosto elevare i privilegi occasionalmente utilizzando `sudo` o un programma grafico che richiede la password. Se vogliamo che un'icona di avvio avvii un'applicazione con tali privilegi, dovremo modificare il comando che esegue o creare un launcher specifico.
Cosa significa davvero eseguire qualcosa come root?
In Linux, root è l'account con UID 0 e privilegi illimitati . Può leggere, modificare o eliminare qualsiasi file, installare software, modificare le configurazioni del kernel e controllare i processi di qualsiasi utente. Questo lo rende uno strumento incredibilmente potente, ma anche un enorme rischio se usato con noncuranza. Un semplice errore di battitura con `rm` o `mv` può rendere il sistema inutilizzabile, e uno script dannoso eseguito come root può installare backdoor, modificare le misure di sicurezza o rubare dati praticamente senza lasciare traccia.
In Ubuntu, l'account root non ha una password predefinita e l'accesso diretto non è consentito. La filosofia è quella di lavorare con il proprio account utente normale e utilizzare `sudo` per attività specifiche . `sudo` significa essenzialmente eseguire un comando come un altro utente, di solito root, dopo essersi autenticati con la propria password se si appartiene al gruppo `sudo`. Questo limita il tempo di esposizione e tiene traccia di chi ha fatto cosa.
Tuttavia, in situazioni molto specifiche, come il ripristino di un sistema danneggiato, il lavoro in ambienti con restrizioni o la configurazione di servizi che richiedono un accesso persistente, potrebbe essere opportuno abilitare temporaneamente i privilegi di root. La raccomandazione generale è di disabilitarli non appena se ne presenti la necessità. Minore è il tempo trascorso come root, maggiore sarà la stabilità e la sicurezza del sistema.
Rischi derivanti dall'uso di radici senza cautela
Uno dei pericoli più evidenti è la cancellazione accidentale di file vitali . Come utente root, non ci sono restrizioni di autorizzazione; un comando come `sudo rm -rf /` può cancellare il sistema senza preavviso. Inoltre, di solito non esiste un cestino per questi file cancellati, quindi il recupero potrebbe richiedere strumenti forensi complessi o addirittura una reinstallazione completa del sistema.
Un altro rischio è rappresentato dall'esecuzione di script non attendibili. Se si esegue codice scaricato da qualsiasi sito con privilegi elevati, è come dargli le chiavi di casa . Anche se lo script sembra innocuo, potrebbe contenere istruzioni dannose o installare malware con privilegi di root. Pertanto, è consigliabile esaminare il codice, utilizzare fonti ufficiali, verificare i checksum e testarlo in una macchina virtuale o in un container prima di eseguirlo in produzione.
Esiste anche un problema di tracciabilità. Quando si utilizza `sudo`, il sistema registra il comando, l'utente che lo ha emesso e l'ora in `/var/log/auth.log`, `/var/log/secure` o `journalctl` . Se si accede direttamente come root, tutto appare come root e si perde la possibilità di sapere quale persona ha apportato ciascuna modifica. In ambienti con più amministratori o in conformità con ISO 27001, PCI DSS o altri standard di audit, questa mancanza di tracciabilità rappresenta una debolezza significativa.
Modi per ottenere privilegi dal terminale
Il metodo più comune e consigliato è quello di anteporre `sudo` a un comando specifico. Ad esempio, per aggiornare i pacchetti, riavviare un servizio o modificare un file protetto, `sudo` richiederà la password del tuo utente, non quella di root, e dopo l'autenticazione eseguirà il comando con privilegi elevati. Se devi eseguirlo come un utente diverso, puoi usare `sudo -u nomeutente comando` . E se ti accorgi di aver dimenticato di usare `sudo`, puoi ripetere l'ultimo comando con `sudo !! `.
Quando si devono eseguire diverse operazioni amministrative di seguito, può essere utile aprire una shell root temporanea. Il comando `sudo -i` simula un accesso root completo, carica l'ambiente root e ti porta nella directory home. Anche `sudo su` o `sudo su -` funzionano, sebbene `sudo -i` sia solitamente più affidabile. Per uscire da questa sessione, è sufficiente digitare `exit`. Si sconsiglia di lasciare una shell root aperta incustodita.
Il comando `su`, invece, permette di cambiare utente. `su - root` o semplicemente `su -` ereditano anche le variabili d'ambiente dell'utente di destinazione, mentre `su root` o `su` senza trattino mantengono parte dell'ambiente precedente. Questa differenza spiega errori come `command not found`: i comandi amministrativi si trovano solitamente in `/usr/local/sbin`, `/usr/sbin` e `/sbin`, percorsi che non sempre compaiono nel PATH di un utente normale. Se si utilizza `su` senza trattino, è necessario digitare il percorso completo o passare a `su -` per ereditare il PATH di root.
Se si desidera abilitare una password per l'utente root, è possibile farlo con il comando `sudo passwd root` . Ubuntu sconsiglia questa pratica, ma tecnicamente consente a root di avere una password. Per bloccare l'account, utilizzare `sudo passwd -l root` , e per sbloccarlo, utilizzare `sudo passwd -u root`. In SSH, l'accesso diretto a root è controllato dal comando `PermitRootLogin` presente nel file `/etc/ssh/sshd_config`. È più sicuro mantenerlo impostato su `no` o, al massimo, su `prohibit-password` per consentire solo le password SSH. Successivamente, è necessario riavviare il servizio SSH.
Configurare i maglioni in modo accurato
Il file `/etc/sudoers` definisce chi può usare `sudo` e per quale scopo. È preferibile non modificarlo manualmente; l'approccio corretto è utilizzare `sudo visudo` , che blocca il file e ne verifica la sintassi prima di salvarlo. La regola di base ha la forma `host utente=(utente_destinazione)`. Ad esempio, `bob ALL=(ALL) ALL` consente a `bob` di eseguire qualsiasi comando come root su qualsiasi macchina. È possibile utilizzare anche i gruppi, come `%admin ALL=(ALL) ALL`.
Per concedere autorizzazioni più precise, si utilizzano gli alias. `User_Alias ADMINS = alice, bob` raggruppa gli utenti, mentre `Cmnd_Alias LOCATE = /usr/sbin/updatedb` raggruppa i comandi. Successivamente, si utilizza `ADMINS ALL = LOCATE` in modo che tali utenti possano eseguire solo quei comandi. È possibile creare alias come `NETWORKING` per comandi quali `route`, `ifconfig`, `ping`, `iptables`, ecc. Questo applica il principio del minimo privilegio senza concedere l'accesso root completo a nessuno.
L' opzione NOPASSWD consente di eseguire determinati comandi senza password, ad esempio `pi ALL=(ALL)`. NOPASSWD: ALL. Questa opzione è comoda, ma pericolosa se usata in modo improprio. Inoltre, ogni utilizzo di `sudo` viene registrato, il che aiuta a controllare gli accessi e a risolvere i problemi. Se qualcosa non funziona, l'analisi di questi log può indicare quale modifica recente ha causato il problema.
Avvio di applicazioni grafiche come root dal launcher
Per i programmi con interfaccia grafica, il semplice utilizzo di `sudo` di solito non funziona bene perché non c'è un terminale che richieda la password. È qui che entrano in gioco gli helper grafici . In KDE, c'è `kdesu` : se sai quale comando avvia l'applicazione, puoi eseguire `kdesu quel_comando`. L'opzione `Esegui comando` nel menu di KDE ti permette anche di avviare un'applicazione come un altro utente inserendo le sue credenziali. Negli ambienti GNOME e GTK , `gksu` e `gksudo` erano ampiamente utilizzati ; questi sono frontend per `sudo` o `su`. Ad esempio, `gksu synaptic` o `gksudo gparted` aprono l'applicazione e chiedono la password.
Nei sistemi moderni, gksu è sconsigliato o addirittura deprecato. La sua alternativa più comune è pkexec , basato su PolicyKit, che permette l'esecuzione dei programmi con privilegi specifici in base a criteri predefiniti. Molti launcher moderni utilizzano pkexec per attività amministrative. Il principio è lo stesso: l'utente non deve aprire un terminale, ma il sistema verifica l'autorizzazione in modo controllato.
Per creare un collegamento nel launcher, è necessario modificare un file .desktop . La riga `Exec` è fondamentale. Se si desidera eseguirlo come root, è possibile utilizzare qualcosa come `Exec=gksu /percorso/al/programma`, `Exec=kdesu /percorso/al/programma` o `Exec=pkexec /percorso/al/programma`. Se si utilizza `sudo` direttamente, è necessario che il launcher abbia `Terminal=true` o configurare un prompt dei comandi grafico. È anche possibile provare a premere Alt+F2 e digitare il comando e il nome del programma, ad esempio `gksu synaptic`. In KDE, `kdesu synaptic` o l'opzione per eseguire come un altro utente svolgono una funzione simile.
Esiste un'alternativa classica chiamata consolehelper , un wrapper per applicazioni GUI. Si crea un collegamento simbolico, ad esempio /usr/bin/xterm-root, che punta a /usr/sbin/consolehelper. Quindi si configura PAM creando il file /etc/pam.d/xterm-root con le autorizzazioni, gli account e le sessioni specificate in config-util. Successivamente, si definisce il file /etc/security/console.apps/xterm-root con USER=root e PROGRAM=/usr/bin/xterm. Quando si esegue xterm-root, consolehelper richiede l'autenticazione PAM e avvia xterm come root. Se si riscontra un errore "Connessione Xlib a :0.0 rifiutata dal server", l'esecuzione di xhost local:root potrebbe essere d'aiuto.
In ogni caso, aprire applicazioni grafiche come root presenta degli svantaggi: mescola le variabili d'ambiente, può interrompere il bus di sessione, influire su Wayland o X11 e creare file con privilegi di root nella directory home. È meglio utilizzarlo solo per specifici strumenti amministrativi e chiuderli non appena si è finito. Non navigare in internet né aprire documenti sospetti come root , perché qualsiasi exploit erediterebbe i privilegi completi.
Esempi comuni di attività che richiedono l'accesso root
Molte operazioni quotidiane richiedono privilegi elevati. La gestione dei pacchetti con apt, zypper, dnf o yum spesso richiede sudo. Ad esempio, `sudo apt update` , `sudo apt install firefox` o `sudo zypper install docker-ce`. Lo stesso vale per i servizi di sistema: `sudo systemctl restart apache2`, `sudo systemctl restart ssh` o `sudo systemctl restart nginx`. Per modificare gli account utente, si usa `sudo usermod`, e per cambiare la proprietà dei file, si usa `sudo chown`. Anche la modifica di configurazioni critiche, come `/etc/ssh/sshd_config`, richiede i privilegi di root se eseguita con nano, vim o gedit.
Non è necessario utilizzare `sudo` per i comandi che si limitano a leggere informazioni o non modificano il sistema, come ad esempio `zypper repos` o `systemctl status NetworkManager`. Usare `sudo` per tutto per abitudine è una cattiva pratica. La cosa più sensata da fare è elevare i privilegi solo quando l'attività lo richiede e poi tornare all'utente normale il prima possibile.
Procedure ottimali quando si lavora con privilegi elevati
Il principio del minimo privilegio dovrebbe guidare ogni azione. Utilizza `sudo` per i singoli comandi quando possibile, evita le shell di root persistenti a meno che non siano assolutamente necessarie ed esci non appena hai finito. Non eseguire script provenienti da fonti sconosciute come root; esamina il codice in anticipo, scarica da repository ufficiali o progetti affidabili, verifica i checksum e testa in un ambiente isolato in caso di dubbi. Una sana dose di scetticismo è una virtù quando si ha a che fare con codice di terze parti che gode di pieni privilegi.
È inoltre consigliabile configurare i privilegi di sudo in modo granulare, senza affidarsi esclusivamente al gruppo sudo per ogni operazione, e tenere traccia dei log. Se si amministrano server, è opportuno controllare i file `/var/log/auth.log`, `/var/log/secure` o utilizzare il comando `journalctl -xe` per rilevare eventuali abusi. Negli ambienti multiutente, sapere chi ha eseguito ciascun comando è fondamentale per garantire la responsabilità e la conformità alle normative di sicurezza.
Abilita e disabilita il root con un head
Se decidi di abilitare l'accesso root, assegna una password con `sudo passwd root`, utilizzala solo per le attività essenziali e poi blocca nuovamente l'account. Per disabilitare l'accesso SSH diretto, modifica il file `sshd_config` e imposta `PermitRootLogin no` o `prohibit-password`, quindi riavvia SSH. Per bloccare l'account localmente, usa `sudo passwd -l root`. Per sbloccarlo, usa `sudo passwd -u root`. Queste misure riducono la superficie di attacco e prevengono attacchi di forza bruta contro l'account più potente.
Nella maggior parte dei casi, la risposta pratica alla domanda iniziale è sì: è possibile avviare un programma dal launcher con privilegi di root utilizzando un'interfaccia grafica come kdesu, gksu, gksudo o pkexec, oppure creando un file .desktop con il comando appropriato. Tuttavia, non è consigliabile lasciare questa impostazione attiva per qualsiasi applicazione. È preferibile avere launcher amministrativi specifici con nomi chiari e utilizzarli solo quando necessario.
Il punto fondamentale è che i privilegi di root non sono un giocattolo e che sudo esiste proprio per darti maggiori poteri senza trasformare ogni clic in un rischio permanente. Se devi avviare un'applicazione grafica come superutente, dai la priorità alle applicazioni che richiedono una password, verifica che l'applicazione ne abbia effettivamente bisogno e limita il suo utilizzo alle attività amministrative. In questo modo, potrai godere della comodità del launcher senza rinunciare alla sicurezza che rende Linux così robusto.