Co to jest SELinux i jak poprawia bezpieczeństwo systemu Linux?

Security-Enhanced Linux (SELinux) to zaawansowany system kontroli dostępu opracowany przez amerykańską Agencję Bezpieczeństwa Narodowego (NSA) w celu wzmocnienia bezpieczeństwa systemów opartych na Linuksie poprzez implementację obowiązkowej kontroli dostępu (Mandatory Access Control – MAC) na poziomie jądra systemu operacyjnego. W przeciwieństwie do tradycyjnych modeli bezpieczeństwa opartych na uprawnieniach użytkownika, SELinux egzekwuje ściśle zdefiniowane polityki bezpieczeństwa, które limitują możliwości procesów i użytkowników niezależnie od ich uprawnień w systemie plików. Niniejszy artykuł przedstawia kompleksowe omówienie architektury SELinux, jego mechanizmów bezpieczeństwa oraz praktycznych sposobów wzmacniania odporności systemów Linux na ataki i eksploatację luk, a także analizuje wyzwania związane z wdrażaniem i konfiguracją.

Spis treści pokaż

Geneza i ewolucja Security-Enhanced Linux

SELinux jest wynikiem wieloletnich prac badawczych Agencji Bezpieczeństwa Narodowego i stanowi implementację zaawansowanego modelu bezpieczeństwa opartego na architekturze Flask (Flux Advanced Security Kernel). Projekt został po raz pierwszy udostępniony publicznie przez NSA w grudniu 2000 roku, a następnie zintegrowany z jądrem Linuksa w wersji 2.6 w sierpniu 2003 roku. Decyzja Linusa Torvaldsa o zaproponowaniu modułowej struktury dla rozszerzeń bezpieczeństwa jądra doprowadziła do utworzenia Linux Security Modules (LSM), frameworka, który umożliwia implementację różnych podejść do bezpieczeństwa bez modyfikowania rdzenia systemu operacyjnego.

Ewolucja SELinux obejmowała kilka kluczowych etapów technicznych. Pierwsze implementacje wykorzystywały persistent security IDs (PSIDs) przechowywane w nieużywanych polach inode systemu plików ext2, jednak rozwiązanie to wymagało modyfikacji każdego typu systemu plików i nie było skalowalne. Następnie SELinux działał jako moduł dla jądra z serii 2.4, przechowując PSID-y w zwykłych plikach, ale podejście to wiązało się z problemami wydajności i brakiem spójności między platformami. Ostatecznie, wraz z integracją w jądrze 2.6 i wsparciem dla LSM oraz rozszerzonych atrybutów (xattrs) w systemie plików ext3, SELinux przeszedł do preferowanego modelu przechowywania informacji o kontekście bezpieczeństwa.

Od integracji z jądrem Linuksa w 2003 roku SELinux stał się standardowym komponentem wielu dystrybucji, w szczególności Red Hat Enterprise Linux, Fedory, CentOS i Rocky Linux. Znaczna część prac nad rozwojem SELinux była wspólnym wysiłkiem NSA, Red Hat i społeczności deweloperów. Dziś SELinux uchodzi za jeden z najskuteczniejszych mechanizmów bezpieczeństwa dla systemów Linux, oferując granularną kontrolę dostępu do zasobów na poziomie jądra.

Fundamenty architektury SELinux i moduł bezpieczeństwa Linuksa

SELinux jest implementacją obowiązkowej kontroli dostępu (MAC) zbudowaną na Linux Security Modules (LSM), które stanowią framework umożliwiający rozszerzeniom bezpieczeństwa wpinanie się w punkty kontroli jądra Linuksa. LSM zapewnia interfejsy pozwalające kontrolować dostęp do obiektów systemu podczas działań procesów i użytkowników, takich jak otwieranie plików, tworzenie katalogów czy bindowanie do portów. Architektura SELinux w jądrze Linuksa jest całkowicie zintegrowana i obsługuje operacje związane z bezpieczeństwem bez konieczności ładowania dodatkowych modułów jądra.

Podstawowym mechanizmem SELinux jest podejmowanie decyzji dotyczących dostępu przez jądro w momencie, gdy proces lub użytkownik chce wykonać operację na obiekcie systemowym. Decyzje są buforowane w Access Vector Cache (AVC), specjalnym cache’u przechowującym uprawnienia dla podmiotów i obiektów. Gdy proces chce uzyskać dostęp do pliku, SELinux najpierw sprawdza AVC. Jeśli informacja nie znajduje się w cache’u, żądanie jest wysyłane do serwera bezpieczeństwa, który porównuje kontekst procesu i pliku z bazą polityki SELinux i na tej podstawie przyznaje lub odmawia dostępu.

Kluczową cechą architektury SELinux jest działanie równoległe do tradycyjnego modelu Discretionary Access Control (DAC) opartego na uprawnieniach uniksowych. Aby operacja została wykonana, zarówno DAC, jak i SELinux muszą ją dopuścić. Jeśli DAC zakazuje dostępu do pliku, SELinux nie jest sprawdzany; jeśli DAC zezwala, a SELinux zabrania – operacja zostaje zablokowana. Ta warstwowa struktura zapewnia dodatkową ochronę, nawet przy błędnie ustawionych uprawnieniach uniksowych.

Dla podsumowania najważniejszych komponentów SELinux na poziomie jądra:

Linux Security Modules (LSM) – punkty zaczepienia w jądrze udostępniające kontrolę nad operacjami na obiektach;
Access Vector Cache (AVC) – pamięć podręczna decyzji dostępowych przyspieszająca egzekwowanie polityki;
serwer bezpieczeństwa SELinux – silnik porównujący konteksty z polityką i zwracający decyzje.

Model obowiązkowej kontroli dostępu w kontraście do kontroli dyskrecjonalnej

Obowiązkowa kontrola dostępu (MAC) implementowana przez SELinux różni się fundamentalnie od tradycyjnego modelu Discretionary Access Control (DAC), który jest standardem w systemach Unix i Linux. W modelu DAC uprawnienia do pliku lub zasobu są określane przez właściciela, a użytkownik lub administrator z odpowiednimi uprawnieniami może je swobodnie zmieniać. Na przykład właściciel może ustawić tryb 777, umożliwiając każdemu odczyt, zapis i wykonanie. W przypadku kompromitacji konta root, atakujący uzyskuje dostęp do plików należących do lub dostępnych dla roota.

W modelu MAC kontrola jest definiowana odgórnie poprzez politykę bezpieczeństwa. Zwykły użytkownik nie może jej zmieniać bez uprawnień administratora – polityka jest zapisana w plikach SELinux i egzekwowana przez jądro. Zasadą fundamentalną w SELinux jest deny-by-default (odmowa domyślna), co oznacza, że wszystko jest zakazane, chyba że polityka wyraźnie coś dopuszcza. Dzięki temu, nawet jeśli atakujący przejmie proces działający z uprawnieniami root, będzie ograniczony do operacji przewidzianych dla jego domeny.

Zasada najmniejszych uprawnień (Principle of Least Privilege – PoLP), która stanowi fundament SELinux, oznacza nadawanie wyłącznie minimalnych uprawnień niezbędnych do realizacji funkcji. To znacząco ogranicza potencjalne szkody wywołane kompromitacją procesu lub konta. Na przykład skompromitowany Apache (httpd) nie uzyska dostępu do plików baz danych czy katalogów domowych użytkowników, jeśli nie są one niezbędne do jego działania.

W DAC uprawnienia są powiązane z właścicielem i grupą, natomiast w SELinux decyzje są niezależne od własności pliku. Oznacza to, że nawet proces z uprawnieniami root może zostać zablokowany przez SELinux, jeśli polityka tego nie dopuszcza. Ta cecha czyni SELinux wyjątkowo skutecznym w ograniczaniu skutków eskalacji uprawnień.

Konceptualne fundamenty – etykiety, domeny i typy

SELinux opiera się na etykietowaniu obiektów i procesów: każdy plik, katalog, proces, port i inne obiekty systemowe mają przypisany kontekst bezpieczeństwa. Ma on postać czterech pól: użytkownik SELinux, rola, typ (dla procesów zwany domeną) oraz poziom bezpieczeństwa (w systemach MLS). Przykładowy kontekst procesu sshd: system_u:system_r:sshd_t:s0.

Typ (type) jest kluczowym elementem w systemach SELinux z polityką targeted, ponieważ mechanizm Type Enforcement (TE) określa na jego podstawie, jakie operacje proces może wykonywać na obiektach. Dla procesów typ bywa nazywany domeną, a dla plików – typem pliku. Etykiety są przypisywane podczas inicjalizacji w procesie etykietowania (labeling), gdzie każdy plik w systemie plików otrzymuje kontekst na podstawie reguł z plików file_contexts (np. wszystkie pliki w /var/www/html/ mogą mieć typ httpd_sys_content_t).

Proces etykietowania jest krytycznie ważny, ponieważ SELinux sprawdza etykiety przy każdej operacji dostępu. Nieprawidłowa etykieta może skutkować odmową dostępu nawet dla procesów, które powinny go mieć. Dlatego przy włączaniu SELinux w systemie, w którym był wyłączony, wszystkie obiekty powinny zostać przeetykietowane (relabeled). Red Hat i Fedora udostępniają do tego narzędzie fixfiles.

Procesy mogą przechodzić między domenami wskutek tzw. domain transition, gdy wykonywany jest plik oznaczony jako punkt wejścia (entrypoint) nowej domeny. Na przykład uruchomienie passwd powoduje przejście z user_t do passwd_t, ponieważ /usr/bin/passwd ma etykietę passwd_exec_t – punkt wejścia do passwd_t. Po zakończeniu wracamy do user_t. Mechanizm ten ogranicza czas istnienia uprzywilejowanych uprawnień do niezbędnego minimum.

Kontrola dostępu oparta na rolach w SELinux

SELinux implementuje Role-Based Access Control (RBAC), bardziej zaawansowany niż standardowy system UNIX. Użytkownik nie wchodzi bezpośrednio do domeny – posiada zestaw ról, a każda rola jest powiązana z zestawem domen. Hierarchia wygląda następująco: użytkownik musi być autoryzowany do roli, rola – do domeny, a domena ogranicza dostęp do określonych typów plików.

Użytkownik może mieć wiele ról, lecz tylko jedna jest domyślna. Po zalogowaniu powłoka startuje w domyślnej roli i domenie. Zmiana roli wymaga polecenia newrole i odpowiednich zezwoleń w polityce. Przykładowo użytkownik pawel może być autoryzowany do roli user_r, a administrator o tej samej nazwie (z innym mapowaniem SELinux) – do roli sysadm_r.

Role stanowią warstwę pośrednią między użytkownikami a domenami, upraszczając zarządzanie uprawnieniami. Zamiast definiowania zasad dla każdego użytkownika, przypisuje się je do ról i dopiero role do użytkowników, co zwiększa spójność i skalowalność w dużych organizacjach.

Tryby operacyjne SELinux i polityki bezpieczeństwa

SELinux może działać w trzech trybach, które określają sposób egzekwowania polityki przez jądro:

Enforcing – polityka jest aktywnie egzekwowana, a niedozwolone operacje są blokowane i logowane; to najwyższy poziom bezpieczeństwa i domyślny tryb w Red Hat Enterprise Linux oraz Fedora;
Permissive – polityka nie jest egzekwowana, ale potencjalne naruszenia są rejestrowane w logach; tryb idealny do testów i debugowania;
Disabled – SELinux jest całkowicie wyłączony, a system działa wyłącznie w modelu DAC.

Zmianę trybu można wykonać poleceniem setenforce (np. setenforce 0 dla permissive i setenforce 1 dla enforcing). Zmiana ta nie przetrwa ponownego uruchomienia; aby ją utrwalić, należy edytować /etc/selinux/config i ustawić zmienną SELINUX na żądaną wartość.

SELinux oferuje różne typy polityk. Targeted policy (polityka ukierunkowana) jest domyślna na większości dystrybucji i chroni wyłącznie wybrane procesy uznawane za podatne, podczas gdy pozostałe działają w domenie unconfined_t. Ułatwia to wdrożenie, bo nie wymaga definiowania zasad dla każdego procesu. Domyślnie chronione są m.in. Apache (httpd), DNS (named), Postfix, SSH (sshd) i inne usługi sieciowe.

MLS policy (Multi-Level Security) to bardziej zaawansowana i restrykcyjna polityka, nakładająca ograniczenia na wszystkie procesy i pliki w systemie. MLS implementuje model Bell–La Padula z poziomami i kategoriami. Jest zwykle stosowana w środowiskach o najwyższych wymaganiach bezpieczeństwa (np. rządowych lub wojskowych) ze względu na złożoność konfiguracji.

Wdrażanie Type Enforcement i reguł dostępu

Type Enforcement (TE) to główny mechanizm kontroli dostępu w SELinux. Każdy proces i plik ma przypisany typ, a reguły polityki definiują, jakie operacje procesy jednego typu mogą wykonywać na obiektach innego typu. Najprostsza reguła TE ma postać: allow source_type target_type:class permissions, gdzie source_type to typ procesu (domena), target_type to typ obiektu (np. pliku), class – klasa obiektu (np. file, directory, socket), a permissions – dozwolone operacje (np. read, write, execute).

Przykład: allow httpd_t httpd_sys_content_t:file { read getattr open } pozwala procesowi Apache (w domenie httpd_t) na odczyt i pobranie atrybutów z plików etykietowanych jako httpd_sys_content_t. Bez tej reguły, nawet przy pozwoleniach DAC, SELinux zablokowałby dostęp.

Reguły SELinux są definiowane w plikach Type Enforcement (.te), a następnie kompilowane do binarnych modułów polityki (.pp). Dystrybucje dostarczają bazową politykę obejmującą standardowe usługi, ale administratorzy mogą tworzyć niestandardowe moduły polityki dla własnych aplikacji. Proces tworzenia reguł polega na identyfikacji akcji, określeniu typów procesów i obiektów oraz zdefiniowaniu reguły allow z odpowiednimi uprawnieniami.

Ważnym konceptem TE jest type transition, określający, jaki typ powinien otrzymać nowo utworzony obiekt w zależności od procesu tworzącego i katalogu nadrzędnego. Na przykład file_type_auto_trans(sshd_t, tmp_t, sshd_tmp_t) oznacza, że jeśli proces w domenie sshd_t tworzy plik w katalogu typu tmp_t, nowy plik ma automatycznie otrzymać typ sshd_tmp_t. Dzięki temu nowe pliki od razu mają właściwe etykiety.

Wielopoziomowe bezpieczeństwo i bezpieczeństwo wielokategoriowe

Oprócz TE, SELinux obsługuje dwa dodatkowe modele: Multi-Level Security (MLS) i Multi-Category Security (MCS). MLS, oparte na modelu Bell–La Padula, wykorzystuje poziomy wrażliwości i kategorie do kontrolowania przepływu informacji. W MLS proces nie może czytać danych o wyższym poziomie (no read up) ani pisać do danych o niższym poziomie (no write down). Przykładowo proces na poziomie „Secret” nie odczyta danych „Top Secret”.

MCS dodano, aby uprościć kategoryzowanie bez zwiększania złożoności dla administratorów. Każdy proces i obiekt (często w kontekście kontenerów) otrzymuje unikalny zestaw kategorii, np. s0:c1,c2. Dwie kategorie mogą się „przecinać” tylko, gdy zestawy są identyczne. Oznacza to, że proces svirt_t:s0:c1,c2 nie uzyska dostępu do obiektu svirt_image_t:s0:c3,c4, nawet jeśli pracują w tej samej domenie.

MCS jest szczególnie przydatny w środowiskach wielodostępnych (multi‑tenant), takich jak wirtualizacja z KVM czy kontenery Docker. Gdy libvirt inicjuje maszynę wirtualną, przypisuje jej unikalną etykietę MCS (np. s0:c1,c2) i oznacza tym samym wszystkie jej zasoby. Nawet jeśli jedna maszyna zostanie skompromitowana przez atakującego z uprawnieniami root, SELinux uniemożliwi dostęp do zasobów innych maszyn.

Praktyczne korzyści bezpieczeństwa i mitygacja podatności

Jedną z głównych korzyści SELinux jest redukcja wpływu luk i exploitów poprzez ograniczenie działań, jakie może wykonać skompromitowany proces. Wbudowana zasada najmniejszych uprawnień sprawia, że przejęty proces zachowuje jedynie minimalne, ściśle zdefiniowane możliwości.

Udokumentowano wiele scenariuszy, w których SELinux ochronił systemy przed atakami. Przykładowo luka CVE-2021-3156 w sudo umożliwiała eskalację uprawnień poprzez przepełnienie bufora. W systemach z SELinux w trybie enforcing domeny procesów sudo są ograniczone do zapisu wyłącznie w określonych miejscach; nawet po eskalacji do roota SELinux blokuje dostęp do wrażliwych plików niezbędnych do działania sudo.

Inny przykład to CVE-2022-0492 – podatność jądra dotycząca cgroup release_agent, umożliwiająca obejście izolacji namespace. Na platformie OpenShift Container Platform (OCP), gdzie SELinux jest domyślnie włączony, podatność jest mitygowana, ponieważ polityka uniemożliwia kontenerom ucieczkę i eskalację. Podobnie, CVE-2019-13272 (dotycząca PTRACE_TRACEME) można ograniczyć, włączając SELinux w trybie enforcing oraz boolean deny_ptrace.

SELinux jest szczególnie skuteczny w mitygacji zero‑day, dla których nie ma jeszcze łatek. Nawet bez poprawki SELinux ogranicza skutki ataku, minimalizując powierzchnię i wektory nadużyć.

Architektura i integracja z innymi systemami bezpieczeństwa

Poza jądrem, SELinux integruje się z wieloma komponentami systemu. Systemd, domyślny init w nowoczesnych dystrybucjach, konsultuje politykę SELinux przy uruchamianiu i zatrzymywaniu usług, co pozwala definiować, którzy użytkownicy lub procesy mogą nimi zarządzać.

SELinux współpracuje z systemem audytu Linuksa, rejestrując wszystkie zdarzenia bezpieczeństwa. Gdy SELinux odmawia dostępu, do /var/log/audit/audit.log trafia wpis ze szczegółami procesu, obiektu, klasy operacji i przyczyny odmowy. Logi audytu są kluczowe do debugowania polityk i zrozumienia blokad SELinux.

W wirtualizacji SELinux integruje się z libvirt poprzez sVirt, zapewniając izolację maszyn wirtualnych. sVirt rozszerza model SELinux na VM, nadając im unikalne etykiety i blokując dostęp do zasobów innych maszyn nawet przy podatnościach hypervisora.

Narzędzia administracyjne i zarządzanie polityką

Najważniejsze narzędzia ułatwiające administrację i diagnostykę w SELinux to:

sestatus – pokazuje status SELinux (włączony/wyłączony, tryb, aktywna polityka, MLS);
getenforce – zwraca bieżący tryb (Enforcing, Permissive lub Disabled);
semanage – zarządza mapowaniem użytkowników, typami portów, kontekstami plików i booleanami (np. semanage port -m -t ssh_port_t -p tcp 9999);
audit2allow – analizuje logi audytu i proponuje reguły dopuszczające zablokowane operacje (należy je weryfikować przed wdrożeniem);
semodule – zarządza modułami polityki SELinux (.pp), m.in. instalacją (semodule -i) i listowaniem (semodule -l).

W nowszych wersjach userspace (3.6) SELinux wprowadził deny rules – reguły usuwające uprawnienia zdefiniowane w bazowej polityce bez jej pełnej rekompilacji, co upraszcza bieżące utrzymanie.

Porównanie z AppArmor – alternatywnym systemem bezpieczeństwa

Poniższa tabela syntetyzuje kluczowe różnice między mechanizmami SELinux i AppArmor:

Aspekt	SELinux	AppArmor
Model kontroli	Label-based z Type Enforcement; decyzje oparte na kontekstach;	Path-based; profile przypisane do ścieżek plików;
Granularność i kontrola	wysoka precyzja, rozbudowane reguły i przejścia typów;	umiarkowana, prostsze profile i łatwiejsza administracja;
MLS/MCS	pełne wsparcie dla MLS i MCS;	brak wsparcia dla MLS/MCS;
Izolacja kontenerów/VM	sVirt, etykiety MCS, izolacja między kontenerami i od hosta;	oddzielenie od hosta, słabsza separacja między kontenerami;
Złożoność wdrożenia	wyższa, wymaga nauki i narzędzi diagnostycznych;	niższa, szybki start i prostsze utrzymanie;
Główne dystrybucje	Red Hat Enterprise Linux, Fedora, CentOS, Rocky Linux;	Ubuntu, Debian, openSUSE/SUSE;

Wyzwania i ograniczenia SELinux

Przy wdrożeniach SELinux warto uwzględnić najczęstsze trudności:

złożoność i krzywa nauki – bogata funkcjonalność wymaga czasu na opanowanie koncepcji i narzędzi;
diagnozowanie problemów – analiza logów audytu i przyczyn odmów bywa czasochłonna;
wydajność – choć narzut zwykle jest niewielki, niektóre operacje (inicjalizacja, tworzenie plików) mogą być wolniejsze;
zakres ochrony – SELinux nie eliminuje exploitów jądra, a jedynie ogranicza skutki w przestrzeni użytkownika.

SELinux powinien być elementem strategii defense in depth, a nie jedynym narzędziem bezpieczeństwa.

Praktyczne scenariusze wdrażania i dobre praktyki

Jeśli włączamy SELinux w systemie, gdzie był wyłączony, bezpieczna procedura wygląda następująco:

Ustaw tymczasowo tryb: edytuj /etc/selinux/config i ustaw SELINUX=permissive;
Wymuś pełne przeetykietowanie: utwórz plik /.autorelabel;
Zrestartuj system i pozwól na automatyczne etykietowanie wszystkich obiektów;
Monitoruj logi audytu, popraw ewentualne etykiety i reguły, a następnie ustaw SELINUX=enforcing i ponownie zrestartuj.

Aby utrzymać stabilne i bezpieczne środowisko z SELinux, stosuj sprawdzone praktyki:

utrzymuj SELinux włączony w produkcji – tryb enforcing znacząco podnosi bezpieczeństwo;
do debugowania używaj permissive zamiast disable – zachowasz logi i unikniesz utraty etykiet;
regularnie analizuj logi audytu – szybciej identyfikujesz błędne etykiety i brakujące reguły;
testuj nowe polityki w środowisku staging – ograniczysz ryzyko regresji w produkcji;
twórz moduły polityk zamiast modyfikować politykę główną – łatwiejsze wersjonowanie i wdrażanie;
inwestuj w szkolenia zespołu – zrozumienie TE, RBAC, MLS/MCS przyspiesza diagnozowanie i zmniejsza liczbę błędów.

Dobrze zarządzona polityka SELinux potrafi znacząco podnieść bezpieczeństwo systemów.

Zaawansowane funkcjonalności i ostatnie zmiany

SELinux ewoluuje, aby wspierać nowoczesne zastosowania. Jednym z ważnych dodatków w userspace 3.6 są deny rules, które pozwalają usuwać uprawnienia z istniejącej polityki bez jej pełnej rekompilacji, co zwiększa elastyczność zarządzania.

SELinux jest aktywnie rozwijany w kontekście bezpieczeństwa kontenerów i Kubernetesa. sVirt i libvirt zapewniają natywne wsparcie w wirtualizacji, a narzędzia takie jak udica generują specyficzne polityki dla niestandardowych kontenerów, ułatwiając ich bezpieczne wdrażanie.

Red Hat pracuje też nad redukcją narzutów wydajnościowych poprzez optymalizacje jądra, zmniejszanie rozmiaru polityk oraz ulepszenia cache’owania, utrzymując SELinux jako praktyczny i wydajny system bezpieczeństwa dla nowoczesnych środowisk.