Products 
SELinux
SELinux
Security Enhanced Linux
16 June 2010
Security Enhanced Linux
Wprowadzenie
W dobie coraz częściej przeprowadzanych ataków na systemy informatyczne, bezpieczeństwo staje się kluczowym i nieodłącznym elementem zarządzania infrastrukturą IT. Podstawą osiągnięcia bezpiecznej infrastruktury jest tzw. hardening czyli utwardzanie systemów operacyjnych.
Red Hat Enterprise Linux to system spełniający normy EAL4+ /LSPP – przede wszystkim dzięki możliwości ograniczenia konta root. Opierający się na modelu obowiązkowej kontroli dostępu MAC (Mandatory Access Control) - mechanizm SELinux - zaimplementowany został do systemu Red Hat Enterprise Linux już od wersji 4 - tym samym dostarczając Klientom system operacyjny domyślnie utwardzony.
Security-Enhanced Linux to rozwiązanie autorstwa Amerykańskiej Agencji Bezpieczeństwa Narodowego NSA (http://www.nsa.gov/selinux/) . Implementacja rozwiązania bazuje na modelu bezpieczeństwa FLASK wraz z połączeniem modeli RBAC,TE i MLS.
Red Hat Enterprise Linux to system spełniający normy EAL4+ /LSPP – przede wszystkim dzięki możliwości ograniczenia konta root. Opierający się na modelu obowiązkowej kontroli dostępu MAC (Mandatory Access Control) - mechanizm SELinux - zaimplementowany został do systemu Red Hat Enterprise Linux już od wersji 4 - tym samym dostarczając Klientom system operacyjny domyślnie utwardzony.
Security-Enhanced Linux to rozwiązanie autorstwa Amerykańskiej Agencji Bezpieczeństwa Narodowego NSA (http://www.nsa.gov/selinux/) . Implementacja rozwiązania bazuje na modelu bezpieczeństwa FLASK wraz z połączeniem modeli RBAC,TE i MLS.
Przeznaczenie
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.
Architektura
1. Przestarzały model polityki DAC
Standardowy model kontroli dostępu DAC wykorzystywany domyślnie w każdym systemie operacyjnym opiera się na przynależności pliku do właściciela | grupy | innych oraz na nadanych uprawnieniach. Wiąże się to z następującymi problemami/podatnościami:
- właściciel obiektu (np. pliku) decyduje o uprawnieniach dotyczących danego obiektu co w konsekwencji oznacza brak kontroli nad nadawanymi uprawnieniami, które mogą być krytycznie niepoprawne (np. rwxrwxrwx, atrybuty suid/sgid)
- brak kontroli nad procesami systemowymi – każdy proces uruchomiony przez użytkownika ma możliwość czytania/modyfikacji innych plików do których użytkownik posiada uprawnienia
- brak rozliczalności czyli brak historii nadawanych uprawnień
- nieograniczony użytkownik root (uid=0)
- brak ochrony przed atakami dnia zerowego (0-day exploits)
Model polityki MAC zasadniczo różni się od uznaniowego modelu kontroli dostępu przede wszystkim dlatego, że bazuje on na polityce bezpieczeństwa, określającej do jakich zasobów użytkownik/proces posiada dostęp.
Koncepcją polityki bezpieczeństwa SELinuksa jest określenie jak najmniejszej ilości uprawnień dla danego obiektu (demona, programu) potrzebnych do jego prawidłowego funkcjonowania. Pozwala to na kompletne wyeliminowanie możliwości uzyskania uprawnień obiektu lub ich ograniczenia do minimum.
SELinux to mechanizm pracujący na poziomie jądra systemu (Linux Security Modules) pozwalający określić w bardzo szczegółowy sposób przydzielenie dostępu do zasobów dla aplikacji pracujących w systemie. Do tego celu wykorzystywany jest tzw. model domen bezpieczeństwa. Polega on na tym, że każdy proces pracujący w ograniczonej domenie (np. httpd_t) zawiera zdefiniowane zasoby do których posiada dostęp (w postaci plików, katalogów, socketów). Operacja ta odbywa się na podstawie przypisanych etykiet.
Koncepcją polityki bezpieczeństwa SELinuksa jest określenie jak najmniejszej ilości uprawnień dla danego obiektu (demona, programu) potrzebnych do jego prawidłowego funkcjonowania. Pozwala to na kompletne wyeliminowanie możliwości uzyskania uprawnień obiektu lub ich ograniczenia do minimum.
SELinux to mechanizm pracujący na poziomie jądra systemu (Linux Security Modules) pozwalający określić w bardzo szczegółowy sposób przydzielenie dostępu do zasobów dla aplikacji pracujących w systemie. Do tego celu wykorzystywany jest tzw. model domen bezpieczeństwa. Polega on na tym, że każdy proces pracujący w ograniczonej domenie (np. httpd_t) zawiera zdefiniowane zasoby do których posiada dostęp (w postaci plików, katalogów, socketów). Operacja ta odbywa się na podstawie przypisanych etykiet.
Przykład 1:
ls -Z /etc/httpd/
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 alias
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.d
lrwxrwxrwx. root root system_u:object_r:httpd_log_t:s0 logs -> ../../var/log/httpd
lrwxrwxrwx. root root system_u:object_r:httpd_modules_t:s0 modules -> ../../usr/lib64/httpd/modules
lrwxrwxrwx. root root system_u:object_r:httpd_config_t:s0 run -> ../../var/run/httpd
ls -Z /var/log/httpd/
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log
semanage port -l | grep http_port_t
http_port_t tcp 80, 443, 488, 8008, 8009, 8443
Poszczególne typy są ściśle powiązane ze sobą – tworząc tym samym domenę bezpieczeństwa np. 'httpd_t' dla serwera Apache.
ls -Z /etc/httpd/
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 alias
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf
drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 conf.d
lrwxrwxrwx. root root system_u:object_r:httpd_log_t:s0 logs -> ../../var/log/httpd
lrwxrwxrwx. root root system_u:object_r:httpd_modules_t:s0 modules -> ../../usr/lib64/httpd/modules
lrwxrwxrwx. root root system_u:object_r:httpd_config_t:s0 run -> ../../var/run/httpd
ls -Z /var/log/httpd/
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log
semanage port -l | grep http_port_t
http_port_t tcp 80, 443, 488, 8008, 8009, 8443
Poszczególne typy są ściśle powiązane ze sobą – tworząc tym samym domenę bezpieczeństwa np. 'httpd_t' dla serwera Apache.
Powyżej wycinek ze źródeł polityki dotyczącej serwera Apache.
Przykład 2:
allow httpd_t httpd_sys_content_t { read getattr };
nadaje domenie skojarzonej (httpd_t) z demonem httpd uprawnienia do czytania zawartości katalogu /var/www oznaczonego etykietą 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 SELinux narzuca restrykcje w sposób bardzo szczegółowy 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).
Podstawową zaletą polityki MAC jest fakt, że 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:
Istnieje ścisłe określenie reguł odczytu plików poprzez poszczególne domeny (httpd_t).
Powyższy przykład ukazuje, że mechanizm SELinux narzuca restrykcje w sposób bardzo szczegółowy 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).
Podstawową zaletą polityki MAC jest fakt, że 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:
Osiągamy dzięki temu efektywną ochronę przed atakami dnia zerowego.
Polityka SELinux definiuje:
- identyfikację użytkownika (user_u)
- przypisaną rolę (user_r)
- typ/domenę (user_t)
- wrażliwość (s0-s1)
- kategorię (c0.c100)
- możliwość przejścia z jednej domeny do drugiej (transition)
Domyślna polityka SELinux dla systemu Red Hat Enterprise Linux to polityka typu targeted, która chroni najczęściej wykorzystywane demony/usługi sieciowe np.:
- httpd (httpd_t)
- dhcpd (dhcpd_t)
- named (named_t)
- portmap (portmap_t)
- ntpd (ntpd_t)
Cała reszta procesów systemowych uruchamiana jest w domenie nieograniczonej (unconfined_t), które korzystają tylko ze standardowego modelu DAC.
SELinux może pracować w trzech trybach:
- enforcing (polityka załadowana, audytowanie aktywne, wykonanie operacji bądź zabronienie wykonania zależne od reguł polityki)
- permissive (polityka załadowana, audytowanie aktywne, wykonanie operacji nawet jeśli polityka zabrania, tzw. „Learning mode” )
- disabled (polityka niezaładowana)
Tylko tryb enforcing gwarantuje skuteczność przeciwdziałania atakom.
3. Rule Based Access Control
Kontrola dostępu na podstawie przyznanej roli to kolejna mocna strona SELinuksa.
Ograniczenie użytkownika systemowego nie sprowadza się już tylko i wyłączenie do sprawdzania dzięki nadanym uprawnieniom – czy użytkownik posiada dostęp do pliku czy też nie.
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.
Ograniczenie użytkownika systemowego nie sprowadza się już tylko i wyłączenie do sprawdzania dzięki nadanym uprawnieniom – czy użytkownik posiada dostęp do pliku czy też nie.
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.
W rzeczywistym przypadku mechanizm RBAC można zastosować, aby przykładowy użytkownik www-admin (uid=0,gid=0) posiadał uprawnienia do:
- restartowania usługi httpd.
- edycji plików konfiguracyjnych usługi httpd.
- odczytywania/modyfikacji logów systemowych dotyczących pracy usługi httpd.
- odczytywania/modyfikowania zawartości stron www serwowanych poprzez usługę httpd.
Mimo. iż użytkownik www-data posiada uid=0 to nie jest w stanie:
- odczytywać/edytować plików systemowych np. /etc/shadow (shadow_t)
- zatrzymać pracy innych usług w systemie np. serwera FTP.
- odczytywać/zapisywać do katalogu domowego użytkownika root /root.
Jakakolwiek inna wykonana akcja spotka się z odmową dostępu oraz odpowiednim poinformowaniem administratora systemu dzięki mechanizmowi auditd.
Dlaczego warto?
SELinux jest niewątpliwie przyszłościowym rozwiązaniem podnoszącym poziom bezpieczeństwa systemu w znaczący sposób. Aktualne trendy związane z przełamywaniem zabezpieczeń wskazują, że typowe mechanizmy utwardzające na nic się zdadzą, programiści nadal będą popełniać błędy, a ich exploitacja, mimo iż coraz trudniejsza – nadal będzie możliwa. Pozostaje więc skorzystanie z sandboxów czyli tzw. „pseudo-jaili” dla chronionych aplikacji, które SELinux dostarcza. Tylko w ten sposób zagwarantujemy naszej infrastrukturze „przetrwanie” do momentu wydania poprawek bezpieczeństwa.
Wsparcie
Firma B2B Sp. z o.o. świadczy profesjonalne usługi wsparcia technicznego dla mechanizmu SELinux pod kątem tworzenia/modyfikacji polityki, jak również administracji i zarządzania mechanizmem w środowisku systemowym Red Hat.
W naszej ofercie posiadamy także zaawansowane szkolenie techniczne „SELinux – tworzenie i zarządzanie polityką bezpieczeństwa”.
W naszej ofercie posiadamy także zaawansowane szkolenie techniczne „SELinux – tworzenie i zarządzanie polityką bezpieczeństwa”.
W razie pytań zapraszamy do kontaktu: Leszek Miś lm [at] bel.pl
- EX200 Kraków
February 10, 2012 (09:00 - 10:00) - EX300 Kraków
February 10, 2012 (09:00 - 10:00) - RH134 Warszawa
February 13, 2012(10:00) - February 16, 2012 (11:00) - EX200 Warszawa
February 17, 2012 (09:00 - 10:00) - EX300 Warszawa
February 17, 2012 (09:00 - 10:00)
