Vorrei avere l'account di root in sicurezza anche se il mio utente non privilegiato è compromesso.
Su Ubuntu puoi usare sudo solo per "motivi di sicurezza" per impostazione predefinita. Tuttavia, non sono sicuro che sia più sicuro del semplice utilizzo dell'accesso su una console in modalità testo. Ci sono troppe cose che possono andare storte se un utente malintenzionato può eseguire il codice come il mio utente normale. Ad esempio, aggiungendo alias, aggiungendo cose al mio PATH, impostando i keylogger LD_PRELOAD e X11 solo per citarne alcuni. L'unico vantaggio che posso vedere è il timeout, quindi non dimentico mai di disconnettermi.
Ho gli stessi dubbi su su ma non ha nemmeno limite di tempo. Alcune operazioni (in particolare il reindirizzamento IO) sono più convenienti con su, ma dal punto di vista della sicurezza sembra essere peggio.
L'accesso su una console in modalità testo sembra essere il più sicuro. Poiché viene avviato da init, se un utente malintenzionato può controllare PATH o LD_PRELOAD è già root. Gli eventi di pressione dei tasti non possono essere intercettati dai programmi in esecuzione su X. Non so se i programmi in esecuzione su X possono intercettare [ctrl]+[alt]+[f1] (e aprire una finestra a schermo intero che sembra una console) o è sicuro come [ctrl]+[alt]+[canc] su Windows. Oltre a ciò l'unico problema che vedo è la mancanza di timeout.
Allora mi sfugge qualcosa? Perché i ragazzi di Ubuntu hanno deciso di consentire solo sudo? Cosa posso fare per migliorare la sicurezza di uno qualsiasi dei metodi?
E l'SSH? Tradizionalmente root non può accedere tramite SSH. Ma usare la logica di cui sopra non sarebbe la cosa più sicura da fare:
- consenti root tramite SSH
- passa alla modalità testo
- accedi come root
- ssh all'altra macchina
- accedere come root?
Risposta accettata:
La sicurezza consiste sempre nel fare compromessi. Proprio come il proverbiale server che è in un sicuro, scollegato, in fondo all'oceano, root sarebbe la maggior parte sicuro se non ci fosse modo di accedervi.
Gli attacchi LD_PRELOAD e PATH come quelli che descrivi presuppongono che ci sia già un utente malintenzionato con accesso al tuo account, o almeno ai tuoi dotfile. Sudo non protegge molto bene da questo:se hanno la tua password, dopo tutto, non c'è bisogno di provare a ingannarti per dopo... possono semplicemente usare sudo ora .
È importante considerare ciò per cui Sudo è stato progettato originariamente:delega di specifici comandi (come quelli per gestire le stampanti) ai “sub-amministratori” (magari studenti laureandi in un laboratorio) senza rivelare completamente il root. Usare sudo per fare tutto è l'uso più comune che vedo ora, ma non è necessariamente il problema che il programma doveva risolvere (da qui la sintassi del file di configurazione ridicolmente complicata).
Ma sudo-for-unrestricted-root lo fa affrontare un altro problema di sicurezza:la gestibilità delle password di root. In molte organizzazioni, questi tendono a essere distribuiti come caramelle, scritti su lavagne e lasciati gli stessi per sempre. Ciò lascia una grande vulnerabilità, poiché la revoca o la modifica dell'accesso diventa un grande numero di produzione. Anche tenere traccia di quale macchina ha quale password è una sfida, per non parlare di tenere traccia di chi sa quale.
Correlati:cosa otterrei quando sudo un programma distruttivo del kernel?Ricorda che la maggior parte della "criminalità informatica" viene dall'interno. Con la situazione della password di root descritta, è difficile rintracciare chi ha fatto cosa:qualcosa sudo con la registrazione remota si occupa abbastanza bene.
Sul tuo sistema di casa, penso che sia davvero più una questione di comodità di non dover ricordare due password. È probabile che molte persone li stessero semplicemente impostando in modo che fossero uguali o, peggio, inizialmente impostandoli in modo che fossero gli stessi e poi lasciandoli non sincronizzati, lasciando marcire la password di root.
Usare le password per niente per SSH è pericoloso, dal momento che i demoni ssh sniffing password vengono messi in atto in qualcosa come il 90% dei compromessi di sistema del mondo reale che ho visto. È molto meglio usare le chiavi SSH e questo può essere un sistema funzionante anche per l'accesso root remoto.
Ma il problema è che ora sei passato dalla gestione delle password alla gestione delle chiavi e le chiavi ssh non sono davvero molto gestibili. Non c'è modo di limitare le copie e se qualcuno ne fa una copia, ha tutti i tentativi che vuole per forzare la passphrase. Puoi stabilire una norma che dice che le chiavi devono essere archiviate su dispositivi rimovibili e montate solo quando necessario, ma non c'è modo di applicarlo e ora hai introdotto la possibilità che un dispositivo rimovibile venga perso o rubato.
La massima sicurezza arriverà tramite chiavi monouso o token crittografici basati su tempo/contatore. Questi possono essere eseguiti nel software, ma l'hardware resistente alle manomissioni è ancora meglio. Nel mondo open source, c'è WiKiD, YubiKey o LinOTP e, naturalmente, c'è anche il massimo proprietario RSA SecurID. Se fai parte di un'organizzazione medio-grande, o anche piccola attenta alla sicurezza, ti consiglio vivamente di esaminare uno di questi approcci per l'accesso amministrativo.
Probabilmente è eccessivo per la casa, però, dove non hai davvero i problemi di gestione, purché tu segua pratiche di sicurezza ragionevoli.