SELinux podstawa bezpiecznej infrastruktury IT 30 październik 2008r. Grupa Emerge firma@emerge.pl
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 (plik ten zawiera hasła wszystkich użytkowników systemowych) rwxrwxrwx root:root 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