Dla administratora wiedzieć wcześniej to poważny atut, stąd się też bierze istnienie całego mnóstwa narzędzi wykrywających incydenty w działających systemach. W przypadku stosowania SELinux a w szczególności dozbrajania go własnymi politykami trafiamy na problem niewystarczająco dobrze opisanych zależności zabezpieczeń. Efekty widzimy w postać tzw. AVC denials im wcześniej je zlokalizujemy tym lepiej.
SELinux oferuje nam kompleksową odpowiedź na wymagania stawiane polityce MAC. Dostarczane polityki bezpieczeństwa dostosowane są do aplikacji standardowo dołączanych do konkretnej dystrybucji. Co jednak gdy zamierzamy uruchomić nieznaną aplikację dla której nieokreślono jeszcze kontekstu bezpieczeństwa, pierwsza rzecz jaka się nasuwa to uzupełnienie takiej polityki bezpieczeństwa. Jest to jednak zadanie dość złożone i czasochłonne, prostszym rozwiązaniem jest skorzystanie z narzędzia sandbox.
Kilka miesięcy temu w cyklu o SELinux poruszyłem temat oznaczania pakietów w systemie netfilter i wiązania ich z polityką bezpieczeństwa:
Najpopularniejszą metodą przetestowania działania SELinux jest uruchomienie serwera WWW oraz przeniesienie pliku np. z lokalizacji /tmp do lokalizacji ,,htdocs'' i próba jego otwarcia z poziomu przeglądarki. Okazuje się, że sztuka ta kończy się niepowodzeniem, pomimo nadania odpowiednich uprawnień. Dzieje się tak, gdyż przeniesiony plik posiada inny kontekst zabezpieczeń, do którego dostępu nie ma serwer WWW. Wystarczy nadać odpowiedni kontekst nowo przeniesionemu plików i problem znika, dzisiaj zatem postaram się rozszyfrować co oznacza odpowiedni kontekst zabezpieczeń dla serwera WWW.
Kolejny wpis z SELinux’em w tytule, tym razem przybliżę moduł SECMARK dla netfilter’a i jego możliwości w kształtowaniu polityk bezpieczeństwa.
Tegoroczna konferencja Red Hat Summit dobiegła końca, pozostał po niej ślad w postaci prezentacji i nagrań wideo dostępnych pod adresem: http://www.redhat.com/promo/summit/2010/presentations/. Tematy, które królowały na konferencji to z pewnością długo oczekiwana wersja RHEL 6 oraz platforma RHEV, jednak nie obyło się też bez omówienia technologii SELinux.
Kolejny wpis z serii SELinux w tytule. Poprzedni wpis koncentrował się na ograniczaniu działania konkretnej aplikacji, tym razem na celownik trafiają użytkownicy.
SELinux umożliwia lepszą kontrolę nad aplikacjami, bez ingerencji w kod danej aplikacji – tak najogólniej brzmi jedno z głównych założeń zaimplementowanego w Linux’ie mechanizmu zabezpieczeń. Sposób realizacji owej lepszej kontroli nad aplikacjami opiera się o implementację MAC (Mandatory Access Control). Otóż każdemu obiektowi w systemie (plik, proces, port etc.) jest przypisany do konkretny typ (label) mając tak zdefiniowaną listę możemy napisać polityki, które np. konkretnemu procesowi (dla przeglądarki www firefox_t) dadzą dostęp do zapisu tylko do określonych plików (np. domowe pliki użytkowników user_home_t) bez względu na uprawnienia dostępu DAC (rwx). Postaram się przedstawić sposób tworzenia polityki dla prostego skryptu oraz opisać korzyści płynące z tego tytułu…