Jak działają wewnętrzne sudo?

Jak sudodziała wewnętrznie? Jak to możliwe, że może stać się rootem bez hasła roota, w przeciwieństwie do su? Jakie syscalls itp. Są zaangażowane w ten proces? Czy nie jest to luka w zabezpieczeniach w systemie Linux (np. Dlaczego nie mogłem skompilować łatki, sudoktóra po prostu robiła to, co sudorobił regularnie , ale nie prosiła o hasło użytkownika nieuprzywilejowanego)?

Przeczytałem login i su internals . Przeczytałem również Jak stosować sudo? ale pomimo tytułu zajmują się głównie różnicami między sui sudo.

Jeśli spojrzysz na plik wykonywalny sudo:

$ which sudo
/usr/bin/sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun  3  2011 /usr/bin/sudo

Zauważysz, że zawiera on bity uprawnień ---s--x--x. Można je podzielić w następujący sposób:

-|--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

Tak więc, gdy program ma włączony bit setuid (zwany również SUID), oznacza to, że gdy ktoś uruchomi ten program, będzie on działał z poświadczeniami użytkownika, który jest właścicielem pliku, inaczej. root w tym przypadku.

Przykład

Jeśli uruchomię następujące polecenie jako użytkownik saml:

$ whoami
saml

$ sudo su -
[sudo] password for saml: 

Zauważysz, że wykonanie sudofaktycznie działa jako root:

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

mechanizm setuid

Jeśli jesteś ciekawy, jak działa SUID, spójrz man setuid. Oto fragment strony podręcznika, który wyjaśnia to lepiej niż ja:

setuid () ustawia efektywny identyfikator użytkownika procesu wywołującego. Jeśli efektywny identyfikator UID osoby dzwoniącej to root, to ustawiany jest również rzeczywisty UID i zapisany set-user-ID. W Linuksie setuid () jest implementowany podobnie jak wersja POSIX z funkcją _POSIX_SAVED_IDS. Pozwala to programowi ustawionemu ID użytkownika (innemu niż root) zrzucić wszystkie jego uprawnienia użytkownika, wykonać pewne nieuprzywilejowane prace, a następnie ponownie połączyć oryginalny efektywny identyfikator użytkownika w bezpieczny sposób.

Jeśli użytkownik jest rootem lub program jest ustawiony na root-ID użytkownika, należy zachować szczególną ostrożność. Funkcja setuid () sprawdza efektywny identyfikator użytkownika wywołującego, a jeśli jest to administrator, wszystkie identyfikatory użytkownika związane z procesem są ustawione na uid. Po tym wystąpieniu program nie może odzyskać uprawnień administratora.

Kluczową koncepcją jest to, że programy mają rzeczywisty identyfikator użytkownika (UID) i efektywny (EUID). Setuid ustawia efektywny identyfikator użytkownika (EUID), gdy ten bit jest włączony.

Z punktu widzenia jądra wiadomo, że w naszym przykładzie samlnadal jest pierwotnym właścicielem (UID), ale EUID został ustalony z kimkolwiek, kto jest właścicielem pliku wykonywalnego.

setgid

Powinienem również wspomnieć, że kiedy rozkładamy uprawnienia do polecenia sudo, druga grupa bitów dotyczyła uprawnień grupowych. Bity grupy mają również coś podobnego do setuid zwanego set group id (alias. Setgid, SGID). Robi to samo co SUID, tyle że uruchamia proces z poświadczeniami grupy zamiast poświadczeń właściciela.

Bibliografia

• strona wikipedia setuid
• strona man setuid

Prawdziwy sudoplik binarny to setuid root i nie można tak po prostu utworzyć plików, które są ustawione w ten sposób.

setuid i setgid (odpowiednio: „ustaw identyfikator użytkownika po wykonaniu” i „ustaw identyfikator grupy po wykonaniu”) [1] są flagami praw dostępu w systemie Unix, które pozwalają użytkownikom uruchamiać plik wykonywalny z uprawnieniami odpowiednio właściciela lub grupy pliku wykonywalnego i zmienić zachowanie w katalogach.

Aby odpowiedzieć na część dotyczącą wywołań systemowych, której nikt chyba nie dotknął, jednym z ważnych wywołań systemowych jest setresuid () lub setresgid (). Jestem pewien, że istnieją inne, ale te 2 wydają się dość specyficzne dla setuid / sudo.