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

20

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.

MS Dousti
źródło
2
Zostało to również zgłoszone tutaj . Chociaż z pewnością jest to teoretycznie możliwe, wydaje mi się trudne (chyba że ograniczysz tego użytkownika root do tego stopnia, że ​​nie będzie w stanie zrobić nic pożytecznego). Pisanie reguł SELinuksa, które naprawdę robią to, co postanowiłeś, jest trudne w najlepszych przypadkach.
Gilles „SO - przestań być zły”,
4
Dzięki najnowszym jądrom użytkownicy inni niż root mogą tworzyć przestrzenie nazw, w których mają UID 0. Ponieważ nie są UID 0 w przestrzeni nazw najwyższego poziomu, nie mogą zaszkodzić systemowi. Zasadniczo nie dostają szansy na szkodę, w przeciwieństwie do podejścia SELinux, w którym wszystkie takie możliwości muszą zostać odebrane. Zobacz jądro: Obsługa przestrzeni nazw i w pełni oddzielne dwa konta bez instalowania osobnych systemów operacyjnych?
Gilles „SO- przestań być zły”,
Zależy od sterownika karty graficznej, czy jest on rzeczywiście bezpieczny, czy nie.
Joshua

Odpowiedzi:

17

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 .

WhiteWinterWolf
źródło
1

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.

strugee
źródło
Po pierwsze, byłem tak pesymistyczny jak ty. Ale zdobywając więcej wiedzy wydaje się, że nie ma potrzeby „uniemożliwiać użytkownikowi root wykonywania jakiejkolwiek akcji”. Sprawdź moją zredagowaną odpowiedź, która zawiera linki i informacje do weryfikacji koncepcji. Niestety nie są już dostępne; ale wydaje się, że wdrożenia nie były poważnie restrykcyjne.
MS Dousti,
-5

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

Otheus
źródło
3
No tak, ale wtedy rootużytkownik po prostu nie jest użytkownikiem root. Pytanie brzmi, czy faktyczny superużytkownik może być w ten sposób ograniczony.
terdon
Brzmi niebezpiecznie - oczywiście z wyjątkiem utworzenia kolejnego konta z identyfikatorem UID 0. Ale byłoby to tak samo jak zmiana nazwy roota i ponowne użycie nazwy „root”.
Volker Siegel,
Pytanie dotyczy tylko „katalogu głównego”, co niekoniecznie jest równoważne z superużytkownikiem, tj. Uid = 0. W rzadkich przypadkach jest to przydatne rozróżnienie.
Otheus
2
Niemniej jednak kontekst wyjaśnia, że ​​OP pyta, czy superużytkownik, a nie jakiś losowy użytkownik, którego nazwa użytkownika rootmoże być ograniczona w taki sposób.
terdon
1
DOBRZE. Przynajmniej edytuj swoją odpowiedź i pokaż, w jaki sposób możesz osiągnąć to, co sugerujesz. Jest ciągle oznaczany jako niskiej jakości ze względu na swoją długość. Dlatego robi się negatywnie.
terdon