Mit czy rzeczywistość: SELinux może ograniczyć użytkownika root?

Gdzieś przeczytałem lub słyszałem (może w kursie LinuxCBT na SELinux ; ale nie jestem pewien), że istnieją internetowe serwery Linux, dla których podane jest również hasło użytkownika root. Serwer Linux jest zahartowany przy użyciu reguł SELinuksa, dzięki czemu każdy może zalogować się z użytkownikiem root, ale nie może wyrządzić szkody systemowi operacyjnemu.

Wydaje mi się to mitem, ale chciałem się upewnić: czy możliwe jest zahartowanie Linux-a (prawdopodobnie za pomocą SELinuksa), tak aby nawet użytkownik root nie mógł wykonywać na nim określonych złośliwych działań? (Przykłady: usuwanie plików systemowych, czyszczenie plików dziennika, zatrzymywanie krytycznych usług itp.)

Taki system Linux będzie świetnym punktem wyjścia do budowy honeypot .

Edycja: Na podstawie odpowiedzi (teraz usuniętej) i małego Googlinga dostałem co najmniej dwa linki, które wskazywały na tak zahartowane serwery Linux. Niestety oba serwery są wyłączone. Dla przypomnienia skopiuję i wkleję opisy tutaj:

1) Ze strony http://www.coker.com.au/selinux/play.html :

Bezpłatny dostęp do roota na maszynie SE Linux!

Aby uzyskać dostęp do mojej gry Debian ssh na play.coker.com.au jako root, hasło to ...

Pamiętaj, że takie maszyny wymagają dużej wprawy, jeśli chcesz je pomyślnie uruchomić. Jeśli musisz zapytać, czy powinieneś je uruchomić, odpowiedź brzmi „nie”.

Ma to na celu wykazanie, że SE Linux może zapewnić wszelkie niezbędne zabezpieczenia bez żadnych uprawnień uniksowych (jednak nadal zaleca się korzystanie z uprawnień uniksowych również w przypadku prawdziwych serwerów). Daje także szansę na zalogowanie się na maszynę SE i zobaczenie, jak to jest.

Kiedy logujesz się na maszynie SE Linux Play, upewnij się, że używasz opcji -x , aby wyłączyć przekazywanie X11 lub ustaw ForwardX11 no w pliku / etc / ssh / ssh_config przed zalogowaniem. Upewnij się także, że używasz opcji -a, aby wyłączyć przekazywanie agenta ssh lub ustaw ForwardAgent no w pliku / etc / ssh / ssh_config przed zalogowaniem. Jeśli nie wyłączysz poprawnie tych ustawień, zalogowanie się do automatu zagrozi Ci atakiem za pośrednictwem klienta SSH.

Istnieje kanał IRC do dyskusji na ten temat, jest to #selinux na irc.freenode.net .

Oto krótkie FAQ

2) Ze strony http://www.osnews.com/comments/3731

Celem wzmocnionego Gentoo jest sprawienie, aby Gentoo był opłacalny w środowiskach serwerowych o wysokim poziomie bezpieczeństwa i stabilności. Ten projekt nie jest samodzielnym projektem odłączonym od Gentoo; ma być zespołem programistów Gentoo, którzy koncentrują się na dostarczaniu Gentoo rozwiązań zapewniających silne bezpieczeństwo i stabilność. Ta maszyna to demo Hardened Gentoo SELinux . Jego podstawowym zastosowaniem jest testowanie i audyt integracji i zasad SELinuksa.

Rzeczywistość: tak, SELinux może ograniczyć użytkownika root.

Jest to możliwe, ponieważ SELinux tak naprawdę nie przejmuje się bieżącym użytkownikiem Uniksa: widzi tylko dodatkowe metadane zwane kontekstem (który obejmuje między innymi pole domeny ) i który pozwala SELinux decydować, czy żądana akcja może zostać autoryzowana, czy nie.

To, co zwykle uważa się za użytkownika root, byłoby mapowane w SELinuksie jako użytkownik root Unixa prowadzący domenę unconfined_tlub sysadm_tSELinux. Jest to klasyczny, wszechmocny, wszechmocny użytkownik root.

Jednak można idealnie skonfigurować swój system do odradzania powłoki root (mam na myśli root użytkownika root Unixa) z uruchomioną user_tdomeną SELinux z ograniczonym dostępem. Zgodnie z polityką SELinuksa taka powłoka nie różni się niczym od powłok innych użytkowników z ograniczonym dostępem i nie ma specjalnych uprawnień w systemie, co skutecznie ogranicza użytkownika root.

Z eksperymentalnego punktu widzenia robienie takich rzeczy dosłownie jest bezużyteczne, jednak podobne praktyki znajdują zastosowanie w prawdziwym świecie. Klasycznym przykładem może być administrator bazy danych, który musi być w stanie zatrzymać / uruchomić demony bazy danych, edytować pliki konfiguracyjne itp. Bez SELinuksa wszystkie te działania wymagałyby od użytkownika eskalacji w kierunku uprawnień roota (nawet jeśli normalnie dotyczy to pojedynczego sudona przykład za pomocą narzędzia, ale nawet to może być podatne na wycieki).

Dzięki SELinux możemy dać temu użytkownikowi prawdziwą powłokę root, ale zamiast uruchamiania unconfined_tlub sysadm_tdomen, będzie on uruchamiał dbadm_tdomenę. Oznacza to, że będzie miał większe uprawnienia niż ograniczony użytkownik, ale te nowe uprawnienia będą ograniczone do tego, co jest potrzebne do administrowania serwerem bazy danych: ten użytkownik nie będzie mógł manipulować innymi usługami, plikami ani uruchamiać innych poleceń administracyjnych niż te ściśle wymagane do wykonania swojej pracy.

W ten sam sposób administratorzy serwera WWW i innych usług mogą mieć również inne powłoki root działające równolegle w tym samym systemie, każdy zobaczy, że ich bieżący użytkownik Uniksa jest rootem , ale dzięki SELinux każdy będzie miał skutecznie różne uprawnienia ograniczone do tego, co jest potrzebny do ich własnych celów .

Tak, to możliwe. Ale niezbyt przydatne.

Teoretycznie możesz uniemożliwić rootowi uruchamianie plików binarnych, które mogłyby być wykorzystywane do szkodliwych celów, egzekwując zasady za pomocą czegoś takiego jak SELinux. Stanowi to jednak problem, który polega na tym, że nawet jeśli użytkownik root został początkowo zabroniony, może po prostu użyć innych metod, aby zmienić lub usunąć polityki SELinux. Z powodu tego problemu trzeba by skutecznie uniemożliwić użytkownikowi root wykonanie jakiejkolwiek czynności, co nie jest zbyt przydatne.

Czy jest możliwe zahartowanie Linux-a (prawdopodobnie za pomocą SELinuksa), tak że nawet użytkownik root nie może wykonywać na nim określonych złośliwych działań?

Może to zabrzmieć tanio, ale to proste: zmień identyfikator użytkownika root użytkownika na niezerowy. Wystarczy przejść do / etc / passwd i / etc / shadow, zmodyfikować istniejące wpisy UID = 0 z „root” na coś innego, a następnie dodać konto o nazwie „root”, którego identyfikator użytkownika nie jest zerowy i nieużywany.

Osiąga cel bez. Jest to również sposób na stwierdzenie, że każdy może mieć „dostęp do konta root” bez faktycznego udzielania eskalowanych uprawnień.