login i su wewnętrzne

Próbuję zrozumieć, w jaki sposób uprawnienia użytkownika działają w systemie Linux. Jądro uruchamia się i uruchamia initjako root, prawda? Następnie Init uruchamia skrypty startowe i uruchamia getty( agetty), ponownie jako root. Agetty po prostu odczytuje nazwę użytkownika i działa login, jak sądzę, nadal jako root. Nic ciekawego jeszcze. Ale co robi logowanie ? Nie mogłem znaleźć nic lepszego niż „próbuje się zalogować”. Załóżmy, że login stwierdza, że ​​hasło jest zgodne (a my próbujemy zalogować się jak zwykły użytkownik), jak to zmienia identyfikator użytkownika? Myślałem, że powinno to być wywołanie systemowe, ale nie byłem w stanie go znaleźć (może jestem po prostu ślepy?)

Także około su. suma ustawiony bit „setuid”, więc kiedy go uruchamiamy, zawsze działa jako root. Ale kiedy mówimy, aby logował się jak zwykły użytkownik, ponownie musi zmienić identyfikator użytkownika. Czy rozumiem poprawnie, że ta sama „magia” zachodzi sui loginkiedy trzeba zmienić użytkownika? Jeśli tak, to dlaczego mają dwa różne programy? Czy podczas logowania się zdarzają się jakieś inne poważne interesy?

Istnieje kilka części tego, co robią programy logowania. Programy logowania różnią się sposobem interakcji z użytkownikiem, który próbuje się zalogować. Oto kilka przykładów:

• login: odczytuje wejście na terminalu tekstowym
• su: wywoływane przez już zalogowanych użytkowników, pobiera większość danych z argumentów wiersza poleceń oraz dane uwierzytelniające (hasło) z terminala
• gksu: podobny do su, ale odczytuje dane uwierzytelniające w X.
• rlogind: uzyskuje dane wejściowe przez połączenie TCP za pośrednictwem protokołu rlogin
• sshd: uzyskuje dane wejściowe przez połączenie TCP za pośrednictwem protokołu SSH
• Menedżery wyświetlania X (xdm, gdm, kdm,…): podobne do login, ale odczytywane dane wejściowe na wyświetlaczu X

Programy te działają w podobny sposób.

1. Pierwszą częścią jest uwierzytelnianie : program odczytuje dane wejściowe od użytkownika i decyduje, czy użytkownik jest upoważniony do zalogowania się. Tradycyjną metodą jest odczytanie nazwy użytkownika i hasła oraz sprawdzenie, czy użytkownik jest wymieniony w bazie danych użytkowników systemu i hasło wpisane przez użytkownika to hasło do bazy danych. Istnieje jednak wiele innych możliwości (hasła jednorazowe, uwierzytelnianie biometryczne, przekazywanie autoryzacji,…).

2. Po ustaleniu, że użytkownik jest uprawniony do zalogowania się i na jakim koncie, program logowania ustala autoryzację użytkownika, na przykład do jakich grup użytkownik będzie należeć w tej sesji.

3. Program logowania może również sprawdzać ograniczenia konta. Na przykład może wymusić czas logowania lub maksymalną liczbę zalogowanych użytkowników lub odmówić określonym użytkownikom niektórych połączeń.

4. Wreszcie program logowania konfiguruje sesję użytkownika. Istnieje kilka podetapów:

   1. Ustaw uprawnienia procesu na to, co zostało określone w autoryzacji: użytkownik, grupy, ograniczenia, ... Tutaj możesz zobaczyć prosty przykład tego podetapu (obsługuje tylko użytkowników i grupy). Podstawową ideą jest to, że program logowania nadal działa w tym momencie jako root, więc ma maksymalne uprawnienia; najpierw usuwa wszystkie uprawnienia inne niż bycie użytkownikiem root, a na koniec wzywa setuiddo usunięcia tego ostatniego, ale nie mniej ważnego uprawnienia.
   2. Prawdopodobnie zamontuj katalog domowy użytkownika, wyświetl wiadomość „masz pocztę” itp.
   3. Wywołaj jakiś program jako użytkownik, zwykle powłokę użytkownika (dla logini su, lub sshdjeśli nie podano polecenia; menedżer wyświetlania X wywołuje menedżera sesji X lub menedżera okien).

Obecnie większość jednorożców korzysta z PAM ( wtykowych modułów uwierzytelniających), aby zapewnić jednolity sposób zarządzania usługami logowania. PAM dzieli swoją funkcjonalność na 4 części : „autoryzacja” obejmuje zarówno uwierzytelnianie (1 powyżej), jak i autoryzację (2 powyżej); „Konto” i „sesja” są jak powyżej 3 i 4; jest też „hasło”, które nie jest używane do logowania, ale do aktualizacji tokenów uwierzytelniających (np. haseł).

Wywołania systemowe, których szukasz, nazywane są takimi rzeczami setuidi seteuidchociaż w rzeczywistości istnieje cała rodzina rąbków w zależności od tego, które warianty tożsamości użytkownika próbujesz zmienić.

Istnieją również równoległe wywołania, takie jak setgidzmiana grupy uruchamianej przez proces.

loginporzuci uprawnienia roota, gdy będzie to konieczne. Wiele programów, które potrzebują uprawnień roota tylko na początku, uruchomi się jako root, zrobi to, co musi, a następnie przejdzie do zwykłego konta użytkownika, aby nie musiały się martwić, że ktoś użyje błędu w pliku binarnym, aby uzyskać dostęp do skorupa korzenia. loginoczywiście posiada przywileje dłużej, ale zasada jest taka sama.

W rzeczywistości upuszczanie uprawnień roota jest dość trywialne. POSIX definiuje setuid()i setgid()funkcje, które odpowiednio zmieniają twoje ID użytkownika i grupy (rzeczywiste i skuteczne, jeśli zaczynasz jako root). loginwywołuje oba te elementy, a także initgroups()konfiguruje dodatkowe grupy, które możesz mieć (ponieważ setgidsłuży to tylko ustawieniu identyfikatora grupy podstawowej)

Oczywiście to jądro obsługuje zmianę UID / GID procesu. Jak znaleźć implementacje wywołań systemowych jądra systemu Linux? wyjaśnia dużo o syscalls; w moim źródle jądra mam:

#define __NR_setgid 144
__SYSCALL(__NR_setgid, sys_setgid)
#define __NR_setuid 146
__SYSCALL(__NR_setuid, sys_setuid)

więc 144 i 146 są numerami wywołań systemowych dla tych funkcji na moim komputerze

Nie sprawdziłem suźródła, aby zobaczyć, co robi, ale podejrzewam, że również upuszcza uprawnienia root'a tuż przed exec()włożeniem powłoki, używając tej samej metody