Perché sudo consente controlli molto più dettagliati rispetto a "accedi come root e poi fai quello che vuoi". Ad esempio puoi configurare sudo in modo che ad alcuni utenti sia consentito eseguire solo determinati comandi (come script wrapper o binari "accettabili"). Sei preoccupato per un cavallo di troia che compromette il computer di un singolo utente, ma sudo è stato creato per consentire la registrazione e il controllo degli accessi su un server amministrato da più persone.
Ovviamente su un sistema a utente singolo, i file importanti sono i file dell'utente e, una volta ottenuto l'accesso all'account dell'utente, hai già accesso a quei file , quindi ottenere la password non è più così importante. Anche se la password è il tuo obiettivo (ad esempio, stai attaccando qualcuno che riutilizza le password) ci sono molti modi per ottenerla senza coinvolgere sudo; ad esempio, di recente ho incontrato 2 programmi installati per impostazione predefinita che registreranno password o errori di password in testo normale.
E infine, è consigliabile non eseguire come root quando possibile perché le conseguenze dell'errata digitazione di un comando (rm_-rf_._/ è un esempio ovvio) non sono così gravi. Richiede il passaggio aggiuntivo di scrivere sudo all'inizio di un comando anziché "dimenticare di aver effettuato l'accesso come root e fare qualcosa di distruttivo" può evitare alcuni errori semplici ma gravi.
Esistono validi usi di convenienza per sudo, ma poiché sono già adeguatamente spiegati in altri post, non li approfondirò molto qui. Ti indicherò comunque sudoers(5) , che è il file di configurazione sudo. Mostra alcune delle configurazioni estese possibili con sudo. Spiegherò quando e perché non dovresti usare sudo per passare dal tuo normale utente a root per motivi puramente di sicurezza, comodità a parte.
Risposta breve: Non c'è modo di utilizzare in modo sicuro sudo se il tuo utente normale potrebbe essere compromesso. Usalo solo per comodità, non per sicurezza. Lo stesso vale per su e tutti gli altri programmi che possono essere utilizzati per elevare il tuo utente abituale a uno più privilegiato.
Risposta lunga: Non è vero che l'utilizzo del percorso completo per sudo ti proteggerà da un ambiente dannoso. Questo è un malinteso comune. Una funzione bash può persino dirottare i nomi che contengono un / all'inizio. Prova a eseguire quanto segue:
$ echo $SHELL
/bin/bash
$ function /usr/bin/sudo { echo "Trust me, now put in your password:"; }
$ /usr/bin/sudo id
Trust me, now put in your password:
Devi usa solo l'opzione 1, ovvero l'accesso con agetty o logind su un tty diverso (nota che su alcune distro, tty1 è dove Xorg è in esecuzione, come Fedora. Sulla maggior parte delle distro, tuttavia, tty1 è un tty di riserva e Xorg funziona su tty7) . Tuttavia , devi essere consapevole che il malware può dirottare ctrl +alt +f1 e presentarti uno schermo falso, quindi devi usare la combinazione Secure Attention Key (SAK, che è alt +sysrq +k su sistemi Linux), che uccide tutti i processi in quel tty. Questo uccide qualsiasi schermata di accesso falsa e ti porta solo a quella vera. Se non ci sono schermate di accesso false che tentano di rubare la tua password di root (che si spera sia il caso), allora agetty si riavvia semplicemente, il che dovrebbe apparire come nient'altro che il prompt di accesso lampeggiante. Su alcuni sistemi, molte funzionalità SysRq sono disabilitate, incluso SAK. Puoi abilitarli temporaneamente tutti scrivendo l'intero 1 in /proc/sys/kernel/sysrq . Il valore di /proc/sys/kernel/sysrq è una bitmap, quindi guarda cosa è attualmente e calcola in cosa devi convertirlo per aggiungere il supporto SAK prima di renderlo permanente in /etc/sysctl.conf . Impostarlo su 1 per sempre può essere una cattiva idea (non vuoi che chiunque sia in grado di alt +sysrq +e uccidere xscreensaver, vero?).
L'idea che tu possa proteggere il tuo utente normale e usare sudo o su in modo sicuro è un'idea molto pericolosa. Anche se fosse possibile, ci sono innumerevoli modi per dirottare la tua sessione di corsa, come LD_PRELOAD , che è una variabile ambientale che punta a un oggetto condiviso (libreria) che verrà forzatamente caricato dal programma per modificarne il comportamento. Sebbene non funzioni su programmi setuid come su e sudo, funziona su bash e su tutte le altre shell, che eseguono su e sudo, e sono quelle che vedono tutte le sequenze di tasti. LD_PRELOAD non è l'unica variabile che può dirottare i programmi in esecuzione come tuo utente. LD_LIBRARY_PATH può dire a un programma di utilizzare librerie dannose invece delle librerie di sistema. Esistono molte altre variabili ambientali che possono essere utilizzate per modificare il comportamento dei programmi in esecuzione in vari modi. Fondamentalmente, se le tue variabili ambientali possono essere compromesse, il tuo utente e tutti i tasti digitati come quell'utente possono essere compromessi.
Se ciò non bastasse, sulla maggior parte delle distribuzioni, il tuo utente può usare ptrace() con il GETREGS o PEEKTEXT/PEEKDATA opzioni per visualizzare tutta la memoria dei processi in esecuzione come lo stesso utente (come il processo bash che sta eseguendo su o sudo per te). Se stai usando una distribuzione che lo disabilita (ad esempio usando Yama LSM), il processo potrebbe essere ancora in grado di leggere e scrivere nella memoria del tuo processo bash usando process_vm_readv() e process_vm_writev() rispettivamente. Su alcuni kernel, puoi anche scrivere direttamente in memoria tramite /proc/pid/mem , purché il processo che vi scrive sia lo stesso utente. Nel kernel Linux, ci sono innumerevoli controlli di sicurezza dappertutto per assicurarsi che i processi non possano interferire tra loro. Tuttavia, coinvolgono tutti inter -protezione dell'utente, non intra -protezione dell'utente. Il kernel di Linux presuppone che ogni singola operazione eseguita come utente A sia attendibile dall'utente A, quindi se esegui il su su root come utente A, allora root deve essere attendibile quanto quell'utente.
Prima ancora di entrare in Xorg, lasciatemi iniziare dicendo che Xorg non fornisce alcuna protezione dai keylogger. Ciò significa che, se usi sudo o su in un tty con Xorg in esecuzione, tutti i processi in esecuzione come lo stesso utente saranno in grado di annusare (e iniettare) sequenze di tasti. Questo perché il modello di sicurezza del protocollo X11 presuppone che qualsiasi cosa con accesso al cookie X11 sia attendibile e che il cookie sia accessibile a tutto ciò che è in esecuzione sotto il tuo utente. È una limitazione fondamentale del protocollo X11, radicata tanto profondamente quanto lo è il concetto di UID su Linux. Non ci sono impostazioni o funzionalità per disabilitare questo. Ciò significa che tutto ciò che digiti in una sessione Xorg, incluso su o sudo (o frontend come gksu, gksudo, kdesu, kdesudo, pinentry, ecc.) può essere intercettato da qualsiasi cosa in esecuzione come lo stesso utente, quindi il tuo browser, i tuoi giochi , il tuo lettore video e, naturalmente, tutto ciò che è stato biforcato dal tuo .bashrc. Puoi verificarlo tu stesso eseguendo quanto segue in un terminale, quindi spostandoti su un altro terminale ed eseguendo un comando con sudo.
$ xinput list
Virtual core pointer id=2 [master pointer (3)]
↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ USB Camera id=10 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Sleep Button id=9 [slave keyboard (3)]
↳ Asus WMI hotkeys id=11 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
$ xinput test 12 # replace 12 with the id number of your keyboard
key press 45
key press 44
key release 40
key press 41
key release 45
key release 44
key release 41
key press 31
^C
Nota che se questo test specifico non funziona per te, significa che non hai i XTEST estensione attiva. Anche se non è attivo, è comunque possibile registrare gli eventi della tastiera utilizzando XQueryKeymap() . La lezione che dovresti imparare è che effettivamente non c'è modo per inserire in modo sicuro la tua password usando su o sudo attraverso un utente compromesso. Devi assolutamente passare a un nuovo tty e utilizzare SAK, quindi accedere direttamente come root.
A parte quanto menzionato dagli altri utenti, sudo mantiene anche l'identità originale dell'utente che sta eseguendo il comando. Significa che puoi tenere traccia di quale userid ha eseguito il comando. Se utilizzi root in un ambiente multiutente, non sarai in grado di tracciare l'esecuzione di un comando per un singolo utente poiché l'uid sarà 0.