Come funziona sudo lavorare internamente? Com'è possibile che possa diventare root senza avere la password di root, a differenza di su ? Quali syscall, ecc. sono coinvolti nel processo? Non è una falla di sicurezza in Linux (ad esempio, perché non ho potuto compilare un sudo pesantemente patchato che ha fatto qualsiasi cosa normale sudo ha fatto, ma non ha chiesto la password dell'utente non privilegiato)?
Ho letto login e su internals. Ho anche letto Come deve essere usato sudo? ma nonostante il titolo, trattano principalmente delle differenze tra su e sudo .
Risposta accettata:
Se dai un'occhiata all'eseguibile sudo :
$ which sudo
/usr/bin/sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun 3 2011 /usr/bin/sudo
Noterai che contiene i bit di autorizzazione ---s--x--x . Questi possono essere suddivisi come segue:
-|--s|--x|--x
- - first dash denotes if a directory or a file ("d" = dir, "-" = file)
--s - only the setuid bit is enabled for user who owns file
--x - only the group execute bit is enabled
--x - only the other execute bit is enabled
Quindi, quando un programma ha il suo bit setuid abilitato (indicato anche come SUID) significa che quando qualcuno esegue questo programma verrà eseguito con le credenziali dell'utente che possiede il file, alias. root in questo caso.
Esempio
Se eseguo il seguente comando come utente saml:
$ whoami
saml
$ sudo su -
[sudo] password for saml:
Noterai che l'esecuzione di sudo in realtà è in esecuzione come root:
$ ps -eaf|grep sudo
root 20399 2353 0 05:07 pts/13 00:00:00 sudo su -
meccanismo setuidico
Se sei curioso di sapere come funziona SUID, dai un'occhiata a man setuid . Ecco un estratto dalla pagina man che lo spiega meglio di me:
setuid() imposta l'ID utente effettivo del processo chiamante. Se l'
UID effettivo del chiamante è root, vengono impostati anche l'UID reale e il set-user-ID salvato
. Sotto Linux, setuid() è implementato come
la versione POSIX con la funzione _POSIX_SAVED_IDS. Ciò consente a un programma
set-user-ID (diverso da root) di eliminare tutti i suoi privilegi utente
, eseguire alcune operazioni senza privilegi e quindi riattivare l'ID utente
effettivo originale in in modo sicuro.
Se l'utente è root o il programma è set-user-ID-root, è necessario prestare particolare attenzione
. La funzione setuid() controlla l'ID utente effettivo di
del chiamante e, se è il superutente, tutti gli ID utente relativi al processo
sono impostati su uid. Dopo che ciò si è verificato, è impossibile per il programma
riottenere i privilegi di root.
Il concetto chiave qui è che i programmi hanno un ID utente reale (UID) e uno effettivo (EUID). Setuid sta impostando l'ID utente effettivo (EUID) quando questo bit è abilitato.
Correlati:Ssh – Come funziona tcp-keepalive in ssh?
Quindi dal punto di vista del kernel è noto che nel nostro esempio, saml è ancora il proprietario originale (UID), ma l'EUID è stato impostato con chi è il proprietario dell'eseguibile.
impostato
Dovrei anche menzionare che quando stiamo analizzando le autorizzazioni sul comando sudo, il secondo gruppo di bit riguardava le autorizzazioni di gruppo. I bit di gruppo hanno anche qualcosa di simile a setuid chiamato set group id (aka. setgid, SGID). Questo fa la stessa cosa di SUID, tranne per il fatto che esegue il processo con le credenziali del gruppo invece delle credenziali del proprietario.
Riferimenti
- pagina wikipedia setuid
- pagina man di setuid