Come funzionano gli interni di sudo?

Come sudofunziona internamente? Come è possibile che possa diventare root senza avere la password di root, a differenza su? Quali syscalls, ecc. Sono coinvolti nel processo? Non è un gap di sicurezza spalancato in Linux (es. Perché non potrei compilare una patch pesante sudoche ha fatto qualunque cosa normale sudo, ma non ha chiesto la password dell'utente senza privilegi)?

Ho letto login e su internals . Ho anche letto Come si usa sudo? ma nonostante il titolo, affrontano principalmente le differenze tra sue sudo.

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 bit setuid abilitato (indicato anche come SUID) significa che quando qualcuno esegue questo programma verrà eseguito con le credenziali dell'utente proprietario del file, aka. root in questo caso.

Esempio

Se eseguo il comando seguente come saml utente:

$ whoami
saml

$ sudo su -
[sudo] password for saml: 

Noterai che l'esecuzione di sudoeffettivamente è in esecuzione come root:

$ ps -eaf|grep sudo
root     20399  2353  0 05:07 pts/13   00:00:00 sudo su -

meccanismo setuid

Se sei curioso di sapere come funziona SUID, dai un'occhiata man setuid. Ecco un estratto dalla pagina man che lo spiega meglio di quanto potrei:

setuid () imposta l'ID utente effettivo del processo di chiamata. Se l'UID effettivo del chiamante è root, vengono impostati anche l'UID reale e l'ID utente set 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 non privilegiate e quindi ripristinare l'ID utente effettivo originale 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 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 recuperare i privilegi di root.

Il concetto chiave qui è che i programmi hanno un vero userid (UID) e uno efficace (EUID). Setuid sta impostando l'ID utente effettivo (EUID) quando questo bit è abilitato.

Quindi dal punto di vista del kernel si sa che nel nostro esempio samlè ancora il proprietario originale (UID), ma l'EUID è stato impostato con chiunque sia il proprietario dell'eseguibile.

setgid

Dovrei anche menzionare che quando stiamo rompendo le autorizzazioni sul comando sudo, il secondo gruppo di bit era per le autorizzazioni di gruppo. I bit di gruppo hanno anche qualcosa di simile a setuid chiamato set group id (aka setgid, SGID). Ciò equivale a SUID, tranne per il fatto che esegue il processo con le credenziali di gruppo anziché le credenziali del proprietario.

Riferimenti

• pagina Wikipedia setuid
• pagina man setuid

Il vero sudobinario è setuid root e non puoi semplicemente far esistere file impostati in questo modo.

setuid e setgid (abbreviazione di "imposta ID utente all'esecuzione" e "imposta ID gruppo all'esecuzione", rispettivamente) [1] sono flag di diritti di accesso Unix che consentono agli utenti di eseguire un eseguibile con le autorizzazioni rispettivamente del proprietario o del gruppo dell'eseguibile e per cambiare il comportamento nelle directory.

Per rispondere alla parte sui syscalls che nessuno sembra aver toccato, uno dei syscalls importanti è setresuid () o setresgid (). Sono sicuro che ce ne sono altri, ma questi 2 sembrano abbastanza specifici per setuid / sudo.