SELinux – podstawa bezpiecznej infrastruktury IT

SELinux – podstawa
bezpiecznej infrastruktury IT
30 październik 2008r.
Grupa Emerge
[email protected]
Wprowadzenie:
Security-Enhanced Linux (w skrócie SELinux) to rozwiązanie autorstwa
Amerykańskiej Agencji Bezpieczeństwa Narodowego - NSA (National Security Agency)
znacząco podnoszące poziom bezpieczeństwa systemu Linux. Implementacja
rozwiązania bazuje na modelu bezpieczeństwa FLASK będącym połączeniem modeli
RBAC,TE i MLS. Projekt przeznaczony jest przede wszystkim dla systemów
korporacyjnych o podwyższonym stopniu ryzyka, jak np. banki i instytucje finansowe,
agencje rządowe i wojskowe, ale także dla małych i średnich firm, które chcą zapewnić
infrastrukturze IT wysoki poziom bezpieczeństwa.
Większość administratorów systemu Linux na pytanie: "Czy używa Pani/Pan
mechanizmu zabezpieczeń SELinux?" odpowiada: "Nie, ponieważ bardzo ciężko jest
wdrożyć ten mechanizm do poprawnego działania produkcyjnego, czyli mowiąc
wprost: wyłączamy go".
Zastanawiające więc, dlaczego o SELinuxie słyszymy coraz więcej i coraz częściej jest
on brany pod uwagę przy planowaniu polityki bezpieczeństwa systemów...
W dokumencie tym chcielibyśmy przedstawić przede wszystkim zasadę działania,
wykorzystywane technologie oraz możliwości rozwiązania jakie otrzymujemy od
autorów mechanizmu SELinux. Jednocześnie pragniemy zwrócić uwagę na pozytywne
aspekty korzystania z tego rozwiązania, a co za tym idzie w sposób odmienny chcemy
zaoferować wdrożenia naszej głównej technologii, w której się specjalizujemy jaką jest
SELinux.
Jako jedyni w Polsce - firma Emerge - profesjonalnie zajmujemy się wdrażaniem
mechanizmu SELinux dla produktów oraz systemów teleinformatycznych naszych
Klientów opartych na systemie Linux. Ten dokument ma być pierwszym z serii
"SELinux - podstawa bezpiecznej infrastruktury", który zachęcać powinien do
skorzystania z naszych usług.
Model DAC:
Zamiast podstawowej polityki DAC (Discretionary Access Control), która znana
jest każdemu administratorowi i użytkownikowi Linuxa, SELinux wprowadza pojęcie
tzw. mechanizmu obowiązkowej kontroli dostępu MAC (Mandatory Access
Control). Aktualnie jednak skupmy się na charakterystyce polityki DAC :
- właściciel obiektu (np. pliku) decyduje o uprawnieniach dotyczących danego obiektu
(model UGO: user-group-other oraz odpowiednie uprawnienia rwxrwxrwx nadane
na pliki i katalogi).
- brak możliwości wprowadzenia jakiejkolwiek kontroli przepływu informacji w systemie
oraz nadawanych uprawnień.
Powyższe cechy, zazwyczaj w większości przypadków są powodem codziennych
problemów związanych z nadużyciami dotyczącymi bezpieczeństwa danych i systemów
informatycznych).
www.emerge.pl
Strona 2
Przyklad1:
Źle nadane uprawnienia na krytyczny plik /etc/shadow dające możliwość odczytania
go lub modyfikacji przez każdego użytkownika w systemie:
# ls -al /etc/shadow
rwxrwxrwx root:root
(plik ten zawiera hasła wszystkich użytkowników
systemowych)
Jest to typowy przypadek potwornego błędu administratora korzystającego z polityki
DAC, który nie zadbał o nadanie poprawnych uprawnień do plików krytycznych
(bądź nie zdążył po zmianie atakującego). Tego rodzaju problem może dotykać
dowolne pliki w systemie.
Mechanizm DAC nie pozwala również na jakże ważną w dzisiejszych czasach ochronę
przed atakami tzw. dnia zerowego (0-day exploits).
Przy założeniu, ze usługa pracująca w systemie uruchomiona jest z konta
nieuprzywilejowanego użytkownika, istnieje możliwość otrzymania przez atakującego
nieautoryzowanego dostępu do systemu.
Typowe ataki związane z przepełnieniami (buffer overflow, stack overflow, itp.)
pozwalają napastnikowi otrzymać dostęp do powłoki systemowej poprzez odpowiednie
wymuszenie uruchomienia kodu w pamięci procesu.
Tym kodem wykonywalnym jest zazwyczaj tzw. shellcode, który daje możliwość
przejęcia uprawnień użytkownika, z którego usługa została uruchomiona.
Umiejętnie skonfigurowany SELinux zapewnia bardzo efektywną ochronę
przeciwko atakom dnia zerowego.
Model DAC jest przestarzały i niewystarczający, dlategoteż należałoby się zastanowić
w którą stronę pójść? Być może w kierunku rozwiązań zwiększających możliwości
polityki DAC czyli ACL (Access Control List), które prędzej czy później przysporzą
ogromnych problemów ze względu na ciągłe rozrastanie się nadawanych uprawnień.
Po drugiej stronie medalu znajduje się innowacyjne rozwiązanie jakim jest polityka
Mandatory Access Control (MAC) w ujęciu o mechanizm SELinux.
www.emerge.pl
Strona 3
Zasada działania mechanizmu Selinux:
Koncepcją polityki bezpieczeństwa SELinuxa jest określenie jak najmniejszej ilości
uprawnień dla danego obiektu (demona, programu, pliku) potrzebnych do jego
prawidlowego funkcjonowania.
Pozwoli to na ograniczenie do minimum możliwości wykorzystania uprawnień po
przejęciu kontroli nad obiektem przez potencjalnych atakujących (np. uprawnienia
użytkownika 'www-data' uzyskane poprzez kompromitację serwera Apache).
Jest to typowy model obowiązkowej kontroli dostępu MAC.
SELinux to mechanizm pracujący na poziomie jądra systemu pozwalający określić w
bardzo szczegółowy sposób przydzielania dostępu do zasobów dla aplikacji pracujących
w systemie.
Wszelkie elementy związane z działaniem systemu, które nie zostały objęte polityką,
bądź są z nią niezgodne są domyślnie zabronione. To podstawowa zaleta polityki MAC,
która jednoznacznie wytyka blędy modelowi DAC.
Globalnie przyjęta zasada głosi, że administrator powinien posiadać informacje
dotyczące zainstalowanych i uruchomionych usług oraz oprogramowania, które
wykorzystywane jest do codziennej pracy.
Administrator zazwyczaj identyfikuje uruchomione usługi poprzez wylistowanie
poszczególnych procesów, np. 'apache2' bądź 'httpd', lub poprzez określenie nazwy
usługi, której dostarczają, np serwer HTTP.
W jednym i drugim przypadku SELinux identyfikuje procesy w postaci domeny, z którą
zostały uruchamione (httpd_t) jak również w postaci punktu wejściowego, który
przyznał te cechy procesom podczas uruchamiania(httpd_exec_t).
Każda domena odpowiada ściśle za uslugę, którą ogranicza, np. MySQL, Bind.
Każda domena posiadać musi unikatową nazwę i unikatowe nazwy elementów
składowych wejściowych (entrypoints) oraz uprawnienia.
Przykład poniżej ilustruje w bardzo uproszczony sposób działanie mechanizmu.
vf
www.emerge.pl
Strona 4
Rysunek 1: Zasada działania mechanizmu SeLinux:
Rule Based Access Control:
Kontrola dostępu na podstawie przyznanej roli to kolejna mocna strona SELinuxa.
Ograniczenie użytkownika systemowego nie sprowadza się już tylko i wyłączenie do
nadanych mu uprawnień w modelu DAC (np. możliwość zapisywania w katalogu /tmp,
ponieważ katalog ten ma uprawnienia 777 czyli do zapisu/odczytu dla wszystkich lub
brak uprawnień odczytywania/zapisu pliku /etc/shadow ponieważ jest on
dostępny do odczytu tylko i wyłącznie dla użytkownika root).
W ujęciu RBAC, podczas logowania, użytkownikowi przydzielana jest specjalna rola,
która ogranicza jego uprawnienia w sposób bardzo restrykcyjny i przede wszystkim
kontrolowany. Nie ma tu miejsca na tzw. wolną amerykankę. Możliwości
wprowadzanych restrykcji jakie daje nam to rozwiązanie są praktycznie nieskończone.
W rzeczywistym przypadku mechanizm RBAC można zastosować, aby przykładowy
użytkownik www-admin (uid=0,gid=0 czyli de facto root - administrator systemu)
posiadał możliwość:
-
restartowania usługi httpd.
edycji plików konfiguracyjnych usługi httpd.
odczytywania logów systemowych dotyczących pracy usługi httpd.
odczytywania/edytowania zawartości stron WWW serwowanych poprzez usługe httpd.
www.emerge.pl
Strona 5
Jakakolwiek inna wykonana akcja spotyka się z odmową dostępu oraz odpowiednim
poinformowaniem administratora systemu dzięki mechanizmowu auditd.
Mimo. iż użytkownik www-data posiada uid=0 to nie jest w stanie na przykład:
- odczytywać/edytować plików systemowych np. /etc/shadow.
- zatrzymać pracy innych usług w systemie np. serwera FTP.
- nasłuchiwać na portach innych niż 80/tcp(HTTP) oraz 443/tcp(HTTPS).
- odczytywać/zapisywać do katalogu domowego użytkownika root /root.
- zrestartować maszyny.
- itd. itp.
Dzięki RBAC-owi nareszcie istnieje możliwość przypisania konkretnych ról dla
konkretnych użytkowników.
Rozwiązanie RBAC bardzo dobrze nadaje się do wdrożenia do produktów opartych o
system Linux - wszelkiego rodzaju routery, firewalle, systemy NAS/iSCSI.
Upraszczając, przy wykorzystaniu mechanizmu SELinux, administrator bezpieczeństwa
w sposób szczegółowy i restrykcyjny zarządza nie tylko uprawnieniami użytkownika
(właściciela procesu), ale przede wszystkim prawami jakie posiada sam proces, czyli co
może, a czego nie może wykonać.
Przykład 2:
allow httpd_t httpd_sys_content_t { read getattr lock ioctl };
daje domenie skojarzonej (httpd_t) z demonem httpd uprawnienia do czytania
kontentu WWW z katalogu np. /var/www (httpd_sys_content_t).
Istnieje ścisłe określenie reguł odczytu plików poprzez poszczególne domeny (httpd_t).
Powyższy przykład ukazuje, że mechanizm SELinuxa narzuca restrykcje w bardzo szczegółowy
sposób już na poziomie wywołań systemowych. Stąd też zdefiniowane zostały wywołania zarówno
dotyczące odczytu atrybutów danego pliku (getattr) jaki i faktycznego odczytu zawartości danego
pliku (read).
www.emerge.pl
Strona 6
Podsumowanie
Wdrożenie SELinuxa jest bardzo trudną operacją związaną przede wszystkim ze znajomością
działania systemu i usług pracujących pod jego kontrolą na naprawdę wysokim poziomie.
W istocie otrzymujemy pewnego rodzaju „firewalla aplikacyjnego”, który podobnie jak filtr
pakietów sieciowych pozwala na dostęp, bądź po prostu go odrzuca i informuje o tym
administratorów. Jesteśmy przekonani, że SELinux to przyszłość bezpiecznej infrastruktury IT.
Misją firmy Emerge jest propagowanie bezpiecznych systemów informatyczanych opartych w
szczególności o darmowe oprogramowanie Opensource.
Uważamy, że bezpieczeństwo danych i informacji to jeden z kluczowych aspektów
biznesu XXI wieku.
Innowacyjne rozwiązania, które oferujemy są również na miarę XXI wieku...
4