Quali sono i vantaggi effettivi dell'assegnazione dei privilegi di sudo a un utente anziché l'utilizzo di root?


25

Sono abbastanza nuovo nell'amministrazione del server e ho visto molti siti che consigliano di assegnare i privilegi di sudo a un utente creato dall'utente root e di fornire all'utente root una password follemente lunga per il miglioramento della sicurezza.

Se l'utente appena creato può svolgere le stesse funzioni di un utente root, qual è il vantaggio effettivo di farlo?


7
Il sudoer non può fare tutto ciò che root può fare, solo ciò che root consente ai sudoer di eseguire il sudo e il sudoer deve ancora eseguire il comando. Infine, sudoers sudo cose come il proprio account utente, il che significa che non devono accedere come root, e in secondo luogo consentire di vedere chi ha sudato qualcosa.
KeithS

Risposte:


48

Ci sono molti vantaggi nell'usare sudola distribuzione della password di root. Senza un ordine particolare:

  • Non stai dando la tua password di root
    Come regola generale, se qualcuno lascia la tua azienda e conosceva la password di root, ora devi andare a cambiare quelle password ovunque. Con una corretta gestione della configurazione questo è un piccolo fastidio. Senza di essa è un lavoro enorme.

  • Non stai dando le chiavi del regno
    sudo ti consente di specificare un elenco limitato di comandi che gli utenti possono eseguire, quindi se decidi che Alice ha bisogno solo della capacità di fermare e avviare Apache, ma Bob ha bisogno dei diritti di root completi che puoi impostare li di conseguenza.

  • È possibile gestire l'autorizzazione a livello centrale che sudo supporta la configurazione LDAP, il che significa che tutti i sistemi dell'azienda possono guardare un server LDAP centrale per determinare chi è autorizzato a fare cosa.
    Devi autorizzare (o annullare l'autorizzazione) di qualcuno? Modifica la configurazione dei sudoers in LDAP e tutti i tuoi sistemi vengono aggiornati contemporaneamente.

  • C'è una pista di controllo
    Con l'eccezione degli utenti che sono autorizzati a fare sudo su -, sudo sho qualcosa di equivalente, sudoprodurrà un audit trail di cui ran utente quali comandi.
    (Produrrà anche un elenco delle persone che si sono date una shell root non ostruita, in modo da poter puntare il dito verso di loro e sibilare in disapprovazione.)

  • sudoè buono per qualcosa di più del semplice root Ognuno si concentra su sudocome fare cose come il su peruser, ma non è tutto per cui è buono.
    Supponiamo che Alice sia responsabile di una particolare build di software, ma Bob dovrebbe essere in grado di eseguire anche lo script di build. Puoi dare a Bob una voce in sudoers che gli consente di eseguire lo script di build come utente di Alice. (Sì, certo, ci sono modi molto migliori per affrontare questo caso particolare, ma il principio di Let user A run a program as user Bpuò essere utile ...).
    Inoltre ottieni tutti gli stessi vantaggi della pista di controllo che ho menzionato sopra quando fai questo ...


1
Risposta molto utile - se so (e intendo con certezza al 100%) che sarò l'unico a gestire un singolo server, vedrai molti vantaggi nell'assegnare i privilegi sudo a un altro utente (che sarei comunque io) oltre a impedirmi di rovinare qualcosa?
JM4,

3
@ Coerenza JM4 e buone pratiche per un giorno in futuro quando lavori in un ambiente più ampio. Da un punto di vista pratico non dovresti mai accedere come root direttamente a meno che tu non sia sulla console fisica a riparare qualcosa che viene regalmente nascosto, quindi sudorispetto a suuna distinzione accademica - dovrai saltare attraverso un cerchio o l'altro. L'uso sudoti offre la possibilità di esercitare il principio del privilegio minimo (il mio ultimo punto) laddove pratico, ed è sempre qualcosa da considerare seriamente.
voretaq7,

2
Inoltre, usa visudo per modificare il tuo file sudoers.
Justin Dearing il

3
Si noti che molti comandi interattivi consentiranno agli utenti di ignorare la pista di controllo. Ad esempio, qualsiasi utente che sudo vipuò :! bashuna volta all'interno di vi.
Dietrich Epp,

4
@DietrichEpp Il NOEXECtag aiuta in questo caso.
Shane Madden

17

La differenza principale è che gli utenti eseguono l'autenticazione sudoutilizzando la propria password, mentre con suo direttamente l'accesso root viene utilizzata la password di root.

Ciò significa che non è necessario condividere la password di root con tutti quanti , e che se in futuro sarà necessario disabilitare l'accesso di root per uno o due utenti, è possibile disabilitarla per loro, invece di dover cambiare il password di root.

sudoè anche in grado di limitare i comandi che ciascun utente può eseguire come root, quindi agli utenti specifici può accedere solo alle attività che devono eseguire, se non richiedono l'accesso completo alla radice.


1
grazie per l'aiuto. Vedo il vantaggio dal tuo punto, ma ho anche visto un utente di base come utente root come un doppio punto di autenticazione dato che ho disabilitato l'accesso utente root da ssh sul mio server.
JM4,

4

Oltre alle risposte fornite, che sono valide, non dimenticare che un utente registrato come root può potenzialmente rompere il sistema ad ogni comando. Se li costringi a digitare sudo prima di fare qualcosa di potenzialmente pericoloso, almeno li rendi conto che devono ricontrollare prima di eseguire un determinato comando.


2

Sì, davvero - dal punto di vista del controllo e della registrazione sudo è molto meglio.

Ad esempio, se si su su l'unico evento acquisito nei registri è che si sta facendo causa. Tutto ciò che segue va come root. E se hai mai guardato i log in Unix / Linux sai che root fa un sacco di cose.

D'altra parte, il Sudo registra praticamente tutto come l'utente originario.


0

L'uso di sudo rende più difficile per un utente malintenzionato accedere a un sistema. Quando esiste un account root sbloccato, un utente malintenzionato conosce il nome utente dell'account che desidera violare prima di iniziare. Quando l'account di root è bloccato, l'utente deve determinare il nome utente e la password per entrare in un sistema.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.