SELinux
Security Enhanced Linux
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.
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)
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.
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.

Przykład 2:
allow httpd_t httpd_sys_content_t { read getattr };
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.
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.
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.
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





