Prawdziwy przykład bezpieczeństwa SELinux?

11

Czy ktoś może podać prawdziwy przykład tego, gdzie SELinux zapisał swój bekon bezpieczeństwa? (lub AppArmour, jeśli chcesz). Jeśli nie twój, wskaźnik do kogoś z wiarygodnym doświadczeniem?

Nie test laboratoryjny, nie biała księga, nie najlepsza praktyka, nie poradnik CERT, ale prawdziwy przykład, coś w rodzaju audytu2, dlaczego pokazanie prawdziwej próby włamania się zatrzymało?

(Jeśli nie masz żadnego przykładu, zostaw komentarz w komentarzach zamiast w odpowiedziach).

Dzięki!

linux security selinux

— kmarsh
źródło

Odpowiedź na to pytanie jest trudna. Problem polega na tym, że gdy systemy nie są zagrożone, nie robią wiadomości. Publikują wiadomości tylko wtedy, gdy są zagrożone. I tak, są wiadomości o wielu zagrożonych systemach CentOS, które zostały skompromitowane właśnie dlatego, że ich administratorzy wyłączyli SELinux, ponieważ nie chcą zawracać sobie głowy nauczeniem się, jak go konfigurować i obsługiwać. Gdyby nie wyłączyli SELinuksa, nie byliby narażeni na szwank.

— Juliano

Dzięki, ale nie szukałam wiadomości bardziej niż osobistych doświadczeń.

— kmarsh

5

Co powiesz na to od Russell Coker ? Jest to przykład z życia, ponieważ zaprosił wszystkich na swoją maszynę jako root. Na pierwszy rzut oka myślałem, że to szaleństwo, ale potem zdajesz sobie sprawę z mocy SELinuksa, która sprawia, że rootowanie jest trochę bezużyteczne.

Oto kilka prawdziwych przykładów z jego strony.

— keithosu
źródło

1

Ciekawy. W pierwszym linku daje dostęp do roota, ale (jak sądzę) blokuje się z SELinuksem w większości przypadków, w których root mógłby normalnie zrobić. Chociaż jest to prawdziwy komputer, kwalifikuje się do prawdziwego życia tylko w taki sam sposób, jak robi to reality show. Ilu SysAdminów skonfigurowałoby maszynę w ten sposób? Drugi link jest tym, czego szukam. Przejrzę je. Dzięki!

— kmarsh

4

SELinux niekoniecznie dotyczy ochrony przed hakerami; chodzi o dokumentowanie i egzekwowanie zasad dotyczących zachowania systemu. Jest to narzędzie w przyborniku, które jest cenne, ale wymaga umiejętności do dobrego korzystania.

Prawdziwy przykład tego, jak cię ratuje, wygląda następująco:

Luka w demonie FTP pozwala anonimowemu użytkownikowi na uzyskanie uprawnień roota. Osoba atakująca wykorzystuje tę lukę w celu uzyskania dostępu do katalogów domowych użytkowników i kradzieży prywatnych kluczy SSH, z których niektóre nie mają hasła.

Jeśli SELinux jest skonfigurowany tak, aby nie zezwalał usługom ftp na odczyt i zapis plików w katalogach domowych użytkowników, exploit nie powiódłby się, a naruszenie zasad byłoby zarejestrowane.

— duffbeer703
źródło

2

To nie jest przykład z prawdziwego życia, to przykład, jak mógłby wyglądać przykład z prawdziwego życia. To hipotetyczny przykład z prawdziwego życia. O co OP nie prosił.

— Jürgen A. Erhard

3

Oto szczegółowy opis ataku, który SELinux zatrzymał, wraz ze szczegółami dziennika i objaśnieniem zastosowanych technik kryminalistycznych. Ten artykuł opublikowałem w Linux Journal:

http://www.linuxjournal.com/article/9176

Oto fragment z początku:

Jeśli operujesz serwerami podłączonymi do Internetu, prawdopodobnie będziesz musiał poradzić sobie z udanym atakiem. W zeszłym roku odkryłem, że pomimo wielowarstwowej obrony na testowym serwerze internetowym (targetbox), atakującemu udało się wykorzystać exploita w częściowo udanej próbie uzyskania dostępu. Na tym serwerze działał system Red Hat Enterprise Linux 4 (RHEL 4) i system zarządzania treścią Mambo. Miał wiele mechanizmów obronnych, w tym Security-Enhanced Linux (SELinux). SELinux uniemożliwił atakującemu wykonanie drugiego etapu ataku, prawdopodobnie uniemożliwiając rootowanie.

W tym artykule przedstawiono studium przypadku reakcji na włamanie, wyjaśniając, w jaki sposób odkryłem włamanie, jakie kroki podjąłem, aby zidentyfikować exploita, jak wyzdrowiałem po ataku i jakie wnioski wyciągnąłem na temat bezpieczeństwa systemu. Zmieniłem nazwy komputerów i adresy IP ze względów prywatności.

— niezrozumiały
źródło