Quale password utente richiede `sudo`?


10
$ ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root 136808 Jul  4  2017 /usr/bin/sudo

pertanto sudoè eseguibile da qualsiasi utente e qualsiasi utente che esegue sudoavrà root come ID utente effettivo del processo perché /usr/bin/sudoè impostato il bit set-user-id di .

Da https://unix.stackexchange.com/a/11287/674

la differenza più visibile tra sudo e su è che sudo richiede la password dell'utente e su richiede la password di root.

  1. Quale password utente sudorichiede? È l'utente rappresentato dall'ID utente reale del processo?

    In caso affermativo, nessun utente può ottenere il privilegio di superutente eseguendo sudoe fornendo quindi la propria password? Linux può limitarlo su alcuni utenti?

  2. È corretto che sudorichiede la password dopo l' execve() inizio dell'esecuzione main()di /usr/bin/sudo?

    Poiché l'euid del processo è stato modificato in root (poiché è impostato il bit set-user-id di / usr / bin / sudo), qual è il punto di sudo che richiede la password in un secondo momento?

Grazie.

Ho letto https://unix.stackexchange.com/a/80350/674 , ma non risponde alle domande precedenti.


3
Non è un utente, ma solo quelli inclusi nell'elenco dei sudoers.
Rodrigo,

1
@Rodrigo Sembra una risposta, inseriscilo in una risposta, non in un commento.
Philip Kendall,

2
@PhilipKendall Che ha risposto solo in parte ai dubbi del PO.
Rodrigo,

Risposte:


22
  1. Nella sua configurazione più comune, sudorichiede la password dell'utente in esecuzione sudo (come dici tu, l'utente corrispondente all'ID utente reale del processo). Il punto sudoè di concedere privilegi extra a utenti specifici (come determinato dalla configurazione in sudoers), senza che tali utenti debbano fornire alcuna autenticazione diversa dalla propria. Tuttavia, sudo fa verificare che l'utente che esegue sudodavvero è chi dicono di essere, e lo fa chiedendo la password (o qualunque sia il meccanismo di autenticazione è configurato per sudo, di solito utilizzando PAM - quindi questo potrebbe comportare un'impronta digitale, oppure a due fattori autenticazione ecc.).

    sudonon garantisce necessariamente il diritto di diventare root, può concedere una varietà di privilegi. Qualsiasi utente autorizzato a diventare root sudoerspuò farlo utilizzando solo la propria autenticazione; ma un utente non può, non può (almeno, non usando sudo). Questo non è imposto da Linux stesso, ma da sudo(e dalla sua configurazione di autenticazione).

  2. sudorichiede davvero la password dopo che è stata avviata; non può fare diversamente ( ovvero non può fare nulla prima che inizi a funzionare). Il punto di sudochiedere la password, anche se è root, è verificare l'identità dell'utente in esecuzione (nella sua configurazione tipica).


12

sudodi solito richiede la password dell'utente che la esegue, anche se può essere configurata :

Diversamente su(1), quando sudoersrichiede l'autenticazione, convalida le credenziali dell'utente che invoca, non le credenziali dell'utente di destinazione (o della radice). Questo può essere modificato attraverso le rootpw, targetpwe runaspwbandiere, descritte più avanti.

L'impostazione rootpwha sudosempre richiesto la password di root, targetpwchiede la password dell'utente sudoalla fine eseguirà il programma e runaspwchiede la password dell'utente impostato runas_default.

Una sudoconfigurazione binaria del genere può effettivamente essere avviata con il privilegio di root da qualsiasi utente. Supponendo che sudonon ci siano bug con il suo codice di autenticazione, che di per sé non avrà molta importanza.

In qualche modo allo stesso modo, qualsiasi processo può anche eseguire codice in modalità kernel, chiamando qualsiasi chiamata di sistema, per esempio open(). (non è lo stesso del codice userpace di root.) Fintanto che il kernel non ha bug, non saranno in grado di eseguire codice arbitrario.


8

Dalla prima riga (e) di man sudo:

DESCRIZIONE
sudo consente a un utente autorizzato di eseguire un comando come superutente o altro utente, come specificato dalla politica di sicurezza. L'ID utente reale (non efficace) dell'utente che invoca viene utilizzato per determinare il nome utente con cui eseguire la query della politica di sicurezza.

Così:

  1. Viene utilizzato l'ID utente reale (non efficace) dell'utente che ha invocato ...
  2. Sì, qualsiasi utente ( autorizzato ) può ottenere il superutente (o altri) privilegi aggiuntivi eseguendo sudo e quindi fornendo l' autenticazione ( configurata ) richiesta. Sia consentito che configurato sono impostati nei file sudoers.

  3. Linux può limitarlo su alcuni utenti?
    Sì, può, ma non lo è. Linux è impostato per consentire al sudo binary di prendere la decisione in base all'insieme di regole (politica di sicurezza) all'interno del programma sudo e all'interno del file /etc/sudoers. Di solito, è possibile utilizzare altri file (anche / invece).

Da man setresuid:

DESCRIZIONE
setresuid () imposta l'ID utente reale, l'ID utente effettivo e l'ID utente set salvato del processo di chiamata.

  1. L'unico modo per ottenere le autorizzazioni di superutente concesse dal kernel è eseguire un programma suid. Non può essere diversamente. È il modo in cui Linux ha scelto di concedere le autorizzazioni per superutente.

  2. Dopo che il kernel ha caricato un eseguibile che non può essere modificato da nessun altro utente (file e directory di proprietà di root e scrivibili solo da root) l'eseguibile stesso (sudo) autentica l'utente chiedendo la sua password (o qualcos'altro come configurato) e decide se e quali autorizzazioni concedere.


-1

Oltre ad altre buone risposte su sudo:

suti consente di diventare effettivamente un altro utente. Sul mio computer non corro come amministratore per l'uso quotidiano, il che significa, tra l'altro, che non posso (direttamente) usare sudo. Se voglio usare sudo, posso usare super "diventare" l'utente Amministratore, e quindi in quel ruolo usare sudo. In quella situazione finisco per inserire la password dell'account Admin due volte - una volta quando corro sue una volta quando corro sudo.

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.