Qual è il modo più sicuro per ottenere i privilegi di root: sudo, su o login?

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" di default. 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 mio normale utente. Ad esempio aggiungendo alias, aggiungendo elementi 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 un limite di tempo. Alcune operazioni (in particolare il reindirizzamento IO) sono più convenienti con su, ma per quanto riguarda la sicurezza questo 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 possano intercettare [ctrl] + [alt] + [f1] (e aprire una finestra a schermo intero che assomiglia a una console) o è sicuro come [ctrl] + [alt] + [del] su Windows. Oltre a ciò, l'unico problema che vedo è la mancanza di timeout.

Quindi mi sto perdendo qualcosa? Perché i ragazzi di Ubuntu hanno deciso di consentire solo sudo? Cosa posso fare per migliorare la sicurezza di uno qualsiasi dei metodi?

Che dire di SSH? Tradizionalmente il root non può accedere tramite SSH. Ma usare la logica sopra non sarebbe questa la cosa più sicura da fare:

• consentire il root tramite SSH
• passa alla modalità testo
• accedi come root
• ssh sull'altra macchina
• accedi come root?

La sicurezza consiste sempre nel fare compromessi. Proprio come il proverbiale server che si trova in un luogo sicuro, non collegato, in fondo all'oceano, rootsarebbe più sicuro se non ci fosse modo di accedervi affatto.

Gli attacchi LD_PRELOAD e PATH come quelli che descrivi presuppongono che ci sia un attaccante con accesso al tuo account già, o almeno ai tuoi dotfile. Il Sudo non lo protegge affatto molto bene: se hanno la tua password, dopo tutto, non c'è bisogno di provare a ingannarti per dopo ... possono semplicemente usarlo sudo ora .

È importante considerare a cosa era stato originariamente progettato Sudo: la delega di comandi specifici (come quelli per gestire le stampanti) a "subamministratori" (forse studenti laureati in un laboratorio) senza dare completamente radice. 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-per-senza restrizioni-root fa affrontare un altro problema di sicurezza: la gestibilità delle password di root. In molte organizzazioni, queste tendono ad essere scambiate come caramelle, scritte su lavagne e lasciate le stesse 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 del monitoraggio chissà quale.

Ricorda che la maggior parte dei "crimini informatici" proviene dall'interno. Con la situazione della password di root descritta, è difficile rintracciare chi ha fatto cosa - qualcosa di sudo con la registrazione remota funziona 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 per essere uguali - o peggio, inizialmente impostandoli allo stesso modo e poi lasciandoli fuori sincrono, lasciando marcire la password di root.

Utilizzo delle password a tutti per SSH è pericoloso, dal momento che da password sniffing daemon SSH trojan sono messe in atto in qualcosa come il 90% dei compromessi del sistema del mondo reale che ho visto. È molto meglio usare le chiavi SSH, e questo può essere un sistema praticabile anche per l'accesso root remoto.

Ma ora il problema è che 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 forzare la passphrase. Puoi stabilire una politica dicendo 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à attraverso chiavi singole o token crittografici time / counter-based. Questi possono essere eseguiti tramite software, ma l'hardware a prova di manomissione è ancora migliore. Nel mondo open source, ci sono WiKiD , YubiKey o LinOTP e, naturalmente, c'è anche il proprietario pesante RSA SecurID . Se fai parte di un'organizzazione medio-grande, o anche piccola, attenta alla sicurezza, consiglio vivamente di esaminare uno di questi approcci per l'accesso amministrativo.

Probabilmente è eccessivo per la casa, tuttavia, in cui non si hanno davvero i problemi di gestione, purché si seguano pratiche di sicurezza sensate.

Questa è una domanda molto complessa. mattdm ha già coperto molti punti .

Tra su e sudo, quando si considera un singolo utente, su è un po 'più sicuro in quanto un utente malintenzionato che ha trovato la propria password non può ottenere immediatamente i privilegi di root. Ma tutto ciò che serve è per l'attaccante di trovare un buco radice locale (relativamente raro) o installare un trojan e attendere che tu esegua su.

Sudo presenta vantaggi anche rispetto all'accesso alla console quando ci sono più utenti. Ad esempio, se un sistema è configurato con registri remoti a prova di manomissione, puoi sempre scoprire chi ha eseguito l'ultima volta sudo (o il cui account è stato compromesso), ma non sai chi ha digitato la password di root sulla console.

Sospetto che la decisione di Ubuntu sia stata in parte nell'interesse della semplicità (solo una password da ricordare) e in parte nell'interesse della sicurezza e della facilità di distribuzione delle credenziali su macchine condivise (affari o famiglia).

Linux non ha una chiave di attenzione sicura o un'altra interfaccia utente sicura per l'autenticazione. Per quanto ne so, anche OpenBSD non ne ha. Se sei così preoccupato per l'accesso root, potresti disabilitare completamente l'accesso root da un sistema in esecuzione: se vuoi essere root, dovresti digitare qualcosa al prompt del bootloader. Questo ovviamente non è adatto a tutti i casi d'uso. (* Il securelevel di BSD funziona in questo modo: a un livello di sicurezza elevato, ci sono cose che non puoi fare senza riavviare, come abbassare il livello di sicurezza o accedere direttamente ai dispositivi raw montati.)

Limitare i modi in cui si può diventare root non è sempre un vantaggio per la sicurezza. Ricorda il terzo membro della triade di sicurezza : riservatezza , integrità , disponibilità . Bloccarsi fuori dal sistema può impedire di rispondere a un incidente.

I progettisti della distribuzione protetta OpenWall GNU / * / Linux hanno anche espresso opinioni critiche su su(per diventare root) e sudo. Potresti essere interessato a leggere questa discussione:

... sfortunatamente sia su che sudo sono sottilmente ma fondamentalmente imperfetti.

Oltre a discutere i difetti sue altre cose, Solar Designer si rivolge anche a un motivo specifico per l'uso su:

Sì, era una saggezza comune tra i sysadmin "su root" piuttosto che effettuare il login come root. Quei pochi che, quando richiesto, potrebbero effettivamente trovare un motivo valido per questa preferenza farebbero riferimento alla migliore responsabilità raggiunta con questo approccio. Sì, questa è davvero una buona ragione a favore di questo approccio. Ma è anche l'unico. ...(leggi di più)

Nella loro distribuzione, hanno "completamente eliminato i programmi root SUID nell'installazione predefinita" (vale a dire, incluso su; e non usano le funzionalità per questo):

Per i server, penso che le persone debbano riconsiderare e, nella maggior parte dei casi, vietare l'invocazione di su e sudo da parte degli utenti. Non c'è sicurezza aggiuntiva dal vecchio "login come non-root, quindi su o sudo per root" sysadmin "saggezza", rispetto al login come non-root e come root direttamente (due sessioni separate). Al contrario, quest'ultimo approccio è l'unico corretto, dal punto di vista della sicurezza:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(Per rendere conto di più amministratori di sistema, il sistema deve supportare la presenza di più account con privilegi di root, come fa Owl.)

(Per i desktop con X, questo diventa più complicato.)

Devi anche assolutamente avere a che fare con ...

A proposito, dovevano sostituire sulogincon msuloginper consentire l'installazione con più account di root: msuloginconsente di digitare il nome utente anche quando si accede alla modalità utente singolo (e preservare la "responsabilità") (queste informazioni provengono da questa discussione in russo ) .

Sembra che tu stia supponendo che l'utilizzo sudopreservi sempre le variabili di ambiente, ma non è sempre così. Ecco un estratto dalla manpage di sudo:

Esistono due modi distinti per gestire le variabili di ambiente. Per impostazione predefinita, l'opzione suvers env_reset è abilitata. Questo fa sì che i comandi vengano eseguiti con un ambiente minimo contenente TERM, PATH, HOME, SHELL, LOGNAME, USER e USERNAME oltre alle variabili del processo di invocazione consentite dalle opzioni suvers env_check ed env_keep. Esiste effettivamente una whitelist per le variabili di ambiente.

Se, tuttavia, l'opzione env_reset è disabilitata nei sudoer, tutte le variabili non esplicitamente negate dalle opzioni env_check ed env_delete vengono ereditate dal processo di invocazione. In questo caso, env_check e env_delete si comportano come una lista nera. Poiché non è possibile inserire nella blacklist tutte le variabili di ambiente potenzialmente pericolose, si consiglia di utilizzare il comportamento predefinito env_reset.

In tutti i casi, le variabili di ambiente con un valore che inizia con () vengono rimosse in quanto potrebbero essere interpretate come funzioni bash. L'elenco delle variabili di ambiente che sudo consente o nega è contenuto nell'output di sudo -V quando eseguito come root.

Pertanto, se env_resetè abilitato (impostazione predefinita), un utente malintenzionato non può ignorare la tua PATHo altre variabili di ambiente (a meno che non le aggiungiate specificamente a una whitelist di variabili che dovrebbero essere conservate).

L'approccio più sicuro è il login ssh usando (almeno) la chiave lunga 2048 (con login password disabilitato) usando un dispositivo fisico per memorizzare la chiave.

Voglio solo aggiungere qualcosa un po 'fuori tema. (per l'argomento selezionare "/ bin / su -" qui dopo)

Penso che la "sicurezza" di cui sopra dovrebbe anche essere collegata ai dati reali che vogliamo proteggere.

Sarà e dovrebbe essere diverso se vogliamo proteggere: my_data, my_company_data, my_company_network.

Di solito, se parlo di sicurezza, parlo anche di "sicurezza dei dati" e backup. Possiamo anche aggiungere sistemi tolleranti ai guasti e simili.

Alla luce di ciò, penso che la sicurezza nel suo insieme sia un equilibrio tra usabilità, "sicurezza dei dati" e gli sforzi necessari per implementare un sistema sicuro.

L'obiettivo di Ubuntu era, e per lo più è ancora, l'utente finale: Sudo è l'impostazione predefinita.

Fedora è la versione gratuita di RedHat che a sua volta è più orientata ai server: il Sudo era disabilitato.

Per le altre distribuzioni non ho informazioni dirette.

Sto usando in questo momento, principalmente, fedora. E da vecchio utente non ho mai digitato "su". Ma posso scrivere "/ bin / su -" in pochissimo tempo anche se non sono esattamente un dattilografo. La variabile PATH .. non dovrebbe essere un problema (scrivo il percorso). Anche il "-" (meno) in linea di principio dovrebbe rimuovere le variabili di ambiente dell'utente e caricare solo quelle di root. cioè evitando alcuni possibili problemi extra. Probabilmente anche LS_PRELOAD.

Per il resto immagino che @mattdm fosse abbastanza preciso.

Ma mettiamolo nella scatola corretta. Supponiamo che uno smart kit di scripting abbia accesso ai miei dati. Cosa diavolo pensi che ci farà? - Pubblica le mie foto? mio? - Stai cercando di scoprire il nome della mia ragazza e dirle che visito siti porno?

Nella foto di un singolo utente le due peggiori situazioni sono: - Il bambino elimina tutti i miei dati: per divertimento o per errore - Il bambino usa la mia macchina per creare un ulteriore attacco a qualche altra entità. O obiettivi simili.

Per il primo caso, ho menzionato sopra, meglio impegnarsi su un backup piuttosto che sulla sicurezza della rete. Sì, sei salvo. Voglio dire, un incidente hardware non è poi così diverso.

Il secondo caso è più sottile. Ma ci sono segnali su queste attività. In ogni caso, puoi fare il possibile, ma non configurerei il mio PC di casa per essere protetto da attacchi terroristici!

Salterò gli altri scenari.

salute F

Se la preoccupazione è che un account utente compromesso possa essere utilizzato per annusare la password utilizzata per sudoo su, quindi utilizzare un passcode monouso per sudoe su.

È possibile forzare l'uso di chiavi per utenti remoti, ma ciò potrebbe non essere necessario per scopi di conformità. Potrebbe essere più efficace configurare un box gateway SSH che richiede un'autorizzazione a due fattori, quindi consentire l'uso della chiave da lì. Ecco un documento su tale configurazione: proteggi la tua distribuzione SSH con l'autenticazione a due fattori WiKID .

Puoi anche dare un'occhiata a privacyIDEA , che non ti offre solo la possibilità di utilizzare OTP per accedere alla macchina (o per fare su / sudo) ma può anche fare OTP offline.

Inoltre è in grado di gestire le tue chiavi SSH. Vale a dire se hai molte macchine e diversi utenti root, tutte le chiavi SSH sono memorizzate centralmente. Quindi è facile "revocare" / eliminare una chiave SSH, se la chiave non può più essere considerata attendibile.

Naturalmente ci sono attività organizzative e flussi di lavoro, per proteggere il sistema.