Bezpieczeństwo SELinux: Kontroluj swój system Linux z dokładnością do milimetra

Informatec Digital » Zasoby » Bezpieczeństwo SELinux: Kontroluj swój system Linux z dokładnością do milimetra

SELinux może brzmieć jak technologia zarezerwowana dla maniaków kernela, ale w rzeczywistości jest to jedno z najpotężniejszych narzędzi bezpieczeństwa dostępnych obecnie w Linuksie . Jeśli zarządzasz serwerami, bezpieczeństwem kontenerów Docker , infrastrukturą chmurową, a nawet komputerami stacjonarnymi o niewielkiej wrażliwości, zrozumienie działania SELinux stanowi o różnicy między systemem, który jest po prostu „dobrze skonfigurowany”, a takim, który trudno złamać, nawet z lukami bezpieczeństwa typu zero-day.

Pomimo reputacji „skomplikowanego”, SELinux oferuje bardzo logiczny model: definiuje, co każdy proces może robić i z jakimi obiektami może się komunikować, a jeśli cokolwiek odbiega od tego skryptu, jądro natychmiast go zatrzymuje . Zamiast ślepo wierzyć, że root będzie się zachowywał prawidłowo lub że demony nie będą miały błędów, SELinux wymusza obowiązkową kontrolę dostępu, która dotyczy nawet superużytkownika, za pomocą bardzo szczegółowych etykiet i zasad.

Czym jest SELinux i jaki problem rozwiązuje?

Security-Enhanced Linux (SELinux) to moduł bezpieczeństwa jądra Linux oparty na LSM (Linux Security Modules). Został pierwotnie opracowany przez NSA we współpracy z Red Hat i innymi partnerami, a od wersji 2.6 jądra stanowi jego oficjalną część. Nie jest to osobna aplikacja, lecz rozszerzenie jądra, które dodaje obowiązkowy system kontroli dostępu (MAC) oraz kontrolę dostępu opartą na rolach (RBAC).

W przeciwieństwie do klasycznej, dyskrecjonalnej kontroli dostępu (DAC) w systemie Unix – uprawnienia właściciela, grupy, innych użytkowników i rwx – w SELinux decyzje o dostępie nie są podejmowane na podstawie wyboru właściciela pliku, lecz na podstawie globalnej polityki ustanowionej przez administratora bezpieczeństwa. DAC jest nadal obecny i ma pierwszeństwo: jeśli DAC odmówi, SELinux nie interweniuje; ale nawet jeśli DAC zezwoli, SELinux może zablokować operację zgodnie ze swoją polityką.

Architektura SELinux wyraźnie rozdziela komponenty: z jednej strony kod jądra, który podejmuje decyzje dotyczące bezpieczeństwa , a z drugiej moduły polityki, które definiują, co jest dozwolone, a co nie. To rozdzielenie pozwala na dostosowanie reguł bez konieczności rekompilacji jądra i usprawnia liczbę komponentów, które mogą wpływać na bezpieczeństwo systemu.

SELinux został domyślnie przyjęty w dystrybucjach takich jak Fedora, Red Hat Enterprise Linux, CentOS i Scientific Linux, a także jest głęboko zintegrowany z systemami takimi jak Android, gdzie służy do ograniczania procesów systemowych i aplikacji do ściśle określonych domen. W świecie BSD i GNU/Linux istnieją alternatywy, takie jak AppArmor, TOMOYO i TrustedBSD (na macOS/FreeBSD), ale SELinux wyróżnia się poziomem szczegółowości, jaki oferuje dla wszystkich obiektów systemowych.

Od DAC-a do MAC-a: dlaczego klasyczny model już nie wystarcza

W tradycyjnym systemie Unix model domena-obiekt jest zarządzany za pomocą DAC: każdy plik lub zasób ma właściciela i uprawnienia, a każdy proces uruchomiony jako ten użytkownik może robić z tymi zasobami, co tylko zechce . Oznacza to, że jeśli demon działa jako root, każdy możliwy do wykorzystania błąd może otworzyć drzwi do kontrolowania połowy systemu za pomocą kontekstu root.

Typowymi przykładami są bazy danych, których pliki danych powinny być przetwarzane wyłącznie za pośrednictwem systemu DBMS, ale które są faktycznie odczytywalne i modyfikowalne przez procesy z głównym UID ; lub krytyczne demony działające z nadmiernymi uprawnieniami. Błąd programowania, przepełnienie bufora lub nieprawidłowa walidacja danych wejściowych mogą przekształcić usługę w autostradę dla całego systemu.

SELinux dodaje warstwę obowiązkowej kontroli dostępu (MAC) na DAC. „Obowiązkowa” oznacza, że ​​kontrola dostępu jest centralnie definiowana przez administratora za pomocą zasad i ani użytkownicy, ani procesy nie mogą samodzielnie tych zasad łamać. System operacyjny egzekwuje te zasady, analizując każdą odpowiednią operację jądra przed jej zezwoleniem.

Jądro, korzystając z haków LSM, odpytuje SELinux o każde wrażliwe wywołanie systemowe (otwieranie plików, tworzenie gniazd, montowanie systemów plików, komunikacja przez IPC itp.). W każdym punkcie decyzyjnym SELinux ocenia operację na podstawie załadowanej polityki oraz kontekstu bezpieczeństwa podmiotu i obiektu . Jeśli polityka nie udziela jawnego pozwolenia, działanie jest odrzucane, niezależnie od tego, czy proces ma uprawnienia roota, czy nie.

Tryby działania: wymuszający, dopuszczający i wyłączony

SELinux może działać w trzech wyraźnie zróżnicowanych stanach operacyjnych, których zrozumienie jest istotne, aby uniknąć problemów w środowisku produkcyjnym:

• EgzekwowanieSELinux jest włączony i w pełni egzekwuje zasady. Wszystkie działania niedozwolonych przez reguły są blokowane i rejestrowane.
• PuszczalskiSELinux jest aktywny, ładuje zasady i etykietuje system plików, ale nie blokuje Rejestruje transakcje tak, jakby zostały odrzucone. Jest to idealne rozwiązanie do debugowania i dostosowywania polityk.
• NiepełnosprawniSELinux jest wyłączony. Żadne zasady nie są stosowane ani tagowanie nie jest wykonywane. System opiera się na klasycznym modelu DAC.

Do szybkich i tymczasowych zmian między trybem wymuszającym a dopuszczającym używa się polecenia `setenforce` , gdzie tryb jest określony jako 0 (dopuszczający) lub 1 (wymagający). Należy pamiętać, że ta zmiana jest nietrwała: po kolejnym ponownym uruchomieniu tryb powróci do trybu zdefiniowanego w konfiguracji.

Jeśli chcesz wprowadzić trwałą zmianę, musisz edytować plik. /etc/selinux/config (lub /etc/sysconfig/selinux w niektórych dystrybucjach) i dostosuj wartość dyrektywy SELINUX=disabled|permissive|enforcingZmiany zostaną zastosowane przy następnym uruchomieniu komputera i w wielu przypadkach będą wiązały się z koniecznością ponownego oznakowania systemu plików.

Aby sprawdzić tryb aktywny, można użyć poleceń takich jak getenforce lub sestatus . Pierwsze z nich zwraca po prostu wartości Enforcing, Permissive lub Disabled; drugie zapewnia pełniejsze podsumowanie statusu SELinux, załadowanych zasad i aktywnych modułów.

Konteksty bezpieczeństwa i system etykietowania

Sercem SELinux jest system etykiet bezpieczeństwa, czyli kontekstów . Każdy plik, proces, port sieciowy, gniazdo, urządzenie itp. ma przypisany kontekst opisujący sposób jego użycia. Kontekst ten składa się z kilku pól, które razem tworzą obraz danego obiektu w SELinux.

Ogólny format kontekstu to user_u:role_r:type_t:level , z pewnymi niuansami zależnymi od polityki (zwłaszcza w przypadku korzystania z MLS/MCS). Każde pole ma określone przeznaczenie: użytkownika SELinux, rolę, typ (nazywany również domeną w odniesieniu do procesów) oraz poziom lub kategorię wrażliwości.

W praktyce najważniejszym elementem jest typ (trzecie pole), ponieważ zdecydowana większość reguł polityki jest formułowana jako relacje między typami . Na przykład, zezwalając procesom typu httpd_t na dostęp do plików oznaczonych jako httpd_sys_content_t lub zezwalając określonej domenie na komunikację z gniazdami oznaczonymi jako http_port_t.

Konteksty te są przechowywane jako rozszerzone atrybuty systemu plikówDlatego kluczowe jest korzystanie z systemów plików obsługujących xattrs (takich jak ext4, XFS itp.). W przypadku procesów bieżący kontekst i inne powiązane konteksty są udostępniane za pośrednictwem pseudosystemu plików. /proc/<pid>/attr/ w plikach takich jak current, exec, fscreate, prev, sockcreate lub keycreate.

Typowe przykłady kontekstów w systemie z ukierunkowaną polityką to:

• system_u:object_r:httpd_sys_content_t:s0 dla treści internetowych obsługiwanych przez Apache lub Nginx.
• system_u:object_r:użytkownik_domowy_t:s0 dla katalogów domowych użytkowników.
• system_u:system_r:httpd_t:s0 dla domeny wykonawczej samego serwera WWW.

Podział komponentów kontekstu SELinux

Gdy natrafisz na kontekst taki jak unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 , może się on wydawać hieroglifem, ale każdy element odpowiada konkretnej koncepcji w ramach SELinux i jego polityce referencyjnej.

El Użytkownik SELinux (zgodnie z konwencją z sufiksem) _uTo nie to samo, co użytkownik Unix w pliku /etc/passwd. SELinux utrzymuje własną bazę danych użytkowników i mapuje ich na użytkowników Linuksa. Użytkownik SELinux może grupować kilku użytkowników Unix, ponieważ ideą jest niezależność warstwy MAC od DAC.

El Rola SELinux (z sufiksem _rDefiniuje to role, jakie może przyjąć użytkownik lub domena. W ścisłym znaczeniu nazywa się to pełnym RBAC. Większość obiektów plikowych korzysta z roli object_r, natomiast role takie jak system_r, user_r, staff_r lub sysadm_r są przypisywane procesom w zależności od kontekstu bezpieczeństwa, jaki muszą przyjąć.

El Typ lub domena SELinux (przyrostek _tW praktyce typ jest kluczowym elementem. Typ opisuje klasę obiektu lub domenę wykonania procesu. Polityka określa, jakie interakcje są dozwolone między typami: które domeny mogą odczytywać, zapisywać, wykonywać lub komunikować się z którymi innymi typami obiektów.

Poziomy i kategorie są używane, gdy włączone są zasady zabezpieczeń wielopoziomowych (MLS) lub wielokategoriowych (MCS). Wrażliwości są hierarchiczne (np. s0, s1 itd.), natomiast kategorie nie (c0, c1, c2 itd.). W środowiskach o wysokim stopniu zagrożenia – na przykład w niektórych organizacjach rządowych – służą one do zapewnienia, że ​​dane mogą być odczytywane tylko w dół i zapisywane tylko na tym samym lub wyższym poziomie , a także do izolowania danych według ściśle określonych przedziałów.

Zasady SELinux: ukierunkowane, ścisłe, MLS/MCS i modułowe

Bezpieczeństwo egzekwowane przez SELinux jest określane przez załadowaną politykę . Polityka to po prostu obszerny zestaw reguł opisujących, jakie działania mogą wykonywać poszczególne domeny i jakie typy danych, a także inne elementy (przejścia, reguły tagowania itp.). Dystrybucje zazwyczaj zawierają standardowe polityki, więc nie trzeba pisać wszystkiego od podstaw.

Najczęściej stosowaną polityką jest tryb ukierunkowany . W tym trybie tylko określone procesy – głównie usługi sieciowe i demony wysokiego ryzyka, takie jak Apache, Nginx, DNS, serwery proxy, SNMP, syslog itp. – działają w ograniczonych domenach. Wszystkie pozostałe procesy użytkownika działają w „nieograniczonych” domenach, gdzie zasadniczo stosowane są standardowe zabezpieczenia systemu Linux, wraz z rejestrowaniem określonych działań.

Istnieje również polityka rygorystyczna , w której praktycznie wszystkie procesy są objęte konkretną polityką. Jest ona znacznie bezpieczniejsza, ale może być również znacznie trudniejsza w utrzymaniu, jeśli model nie jest dobrze zrozumiany, ponieważ wszelkie rozbieżności w etykietowaniu lub regułach mogą zakłócić standardowe przepływy pracy.

W środowiskach o wysokim poziomie bezpieczeństwa istnieją polityki MLS/MCS (Multi-Level/Multi-Category Security) , które wykorzystują wrażliwość i kategorie, aby zapewnić jeszcze bardziej precyzyjne kontrole. Są one typowe dla bardzo sztywnych środowisk wojskowych lub administracyjnych i rzadko są stosowane poza określonymi kontekstami ze względu na wysoką złożoność operacyjną.

Nowoczesne polityki są dystrybuowane modułowo . Zamiast pojedynczego, monolitycznego pliku polityki, dla poszczególnych usług używane są oddzielne moduły, co znacznie upraszcza zarządzanie i aktualizacje. Modułami tymi zarządza się za pomocą narzędzi takich jak semodule i semanage module , które umożliwiają instalację, usuwanie, włączanie lub wyłączanie części polityki bez konieczności ponownej kompilacji całej polityki za każdym razem.

Jak SELinux decyduje: podmioty, obiekty, klasy i uprawnienia

Gdy proces (podmiot) próbuje uzyskać dostęp do zasobu (obiektu), SELinux koncepcyjnie stawia pytanie: „Czy domena typu X może wykonać operację Y na obiekcie typu Z należącym do klasy C?” . Odpowiedź jest następnie poszukiwana w polityce poprzez zdefiniowane reguły.

W zasadach egzekwowania typów (TE), z których korzysta większość dystrybucji i system Android, każdy obiekt należy do klasy (plik, katalog, fifo_file, tcp_socket, proces itd.), a zasady definiują, jakie uprawnienia są dostępne dla każdej klasy: odczyt, zapis, wykonywanie, wiązanie, łączenie, getattr, otwieranie i długie itd.

Zasady TE są wyrażone bardzo wprost. Podstawowym przykładem może być:

zezwól na httpd_t http_port_t:tcp_socket name_bind;

Dzięki tej regule polityka wskazuje, że procesy w domenie httpd_t mogą wykonywać operację name_bind na gniazdach TCP oznaczonych jako http_port_t. Podejście to koncentruje się na typach i klasach obiektów, a nie na konkretnych ścieżkach , co zapobiega niespodziankom podczas przenoszenia plików lub zmiany struktury katalogów.

Na przykład w systemie Android atrybuty SELinux służą do grupowania typów pod bardziej ogólnymi etykietami, takimi jak `appdomain` , dzięki czemu pojedyncza reguła może mieć zastosowanie do wielu domen (`untrusted_app`, `isolated_app` itd.) bez powtarzania definicji. Makra, takie jak `rw_file_perms`, służą również do grupowania kilku wspólnych uprawnień do plików i ograniczania błędów spowodowanych przeoczeniami.

Statusy wewnętrzne, AVC i rejestr odmów

W przypadku żądania dostępu, SELinux najpierw konsultuje się z pamięcią podręczną wektorów dostępu (AVC) , która przechowuje ostatnie decyzje dostępu, aby przyspieszyć proces. Jeśli decyzja znajduje się już w pamięci podręcznej, jest ona wykorzystywana bezpośrednio; w przeciwnym razie odpytywana jest zapora sieciowa (wewnętrzna część SELinux w jądrze), która ocenia operację na podstawie polityki oraz kontekstu podmiotu i obiektu.

Jeśli nie ma reguły, która wyraźnie zezwala na żądaną akcję, domyślną decyzją jest odmowa . Ta filozofia „domyślnego odrzucania” jest jednym z filarów SELinux i zapewnia mu odporność na błędy konfiguracji permisywnej.

Gdy w trybie wymuszania wystąpi odmowa, jądro rejestruje komunikat typu avc: odmówiono w logach systemowych. W zależności od dystrybucji może pojawić się w /var/log/audit/audit.logW /var/log/messages lub zostać przechwycone przez demona auditd. Wiadomości te obejmują kontekst procesu (scontext), kontekst obiektu (tcontext), klasę, żądaną operację i inne dane bardzo przydatne podczas debugowania.

W trybie permisywnym operacja jest dozwolona, ​​ale zdarzenie avc: denied jest nadal generowane i oznaczone jako permissive=1. To prawdziwa skarbnica wiedzy o tworzeniu i dostosowywaniu zasad, ponieważ pozwala zobaczyć, co mogłoby spowodować awarię systemu, gdyby egzekwowanie zasad zostało wdrożone bez przerywania normalnego działania.

Integracja SELinux z dystrybucjami i systemem Android

W ekosystemie serwerów i komputerów stacjonarnych Linux funkcja SELinux jest domyślnie włączona Fedora, RHEL, CentOS i pochodneDebian i Ubuntu zapewniają pełne wsparcie w swoich jądrach i pakietach, chociaż aktywacja jest zwykle opcjonalna i wymaga zainstalowania pakietów takich jak selinux-basics, selinux-policy-default i auditd, a następnie globalnego ponownego tagowania za pomocą fixfiles relabel.

System Android początkowo włączył SELinux w wersji 4.3 w trybie permisywnym, przechodząc do częściowego użycia w wersji 4.4 (tylko dla krytycznych domen, takich jak installd, netd, vold i zygote), a od wersji Android 5.0 jest on w pełni zintegrowany . Polityka Androida koncentruje się na izolowaniu aplikacji, usług systemowych i wrażliwych procesów za pomocą typów i atrybutów, mając na celu zminimalizowanie wpływu naruszenia na którykolwiek z tych komponentów.

Android wykorzystuje koncepcje takie jak typ untrusted_app dla typowych procesów aplikacji, atrybuty appdomain do grupowania domen aplikacji oraz kategorie MLS/MCS do izolowania danych między aplikacjami i użytkownikami fizycznymi. Wszystkie te elementy działają razem, aby zapobiec wydostaniu się zainfekowanej aplikacji z piaskownicy, nawet jeśli uzyska ona bardzo szerokie uprawnienia użytkownika.

Ważne: Android upraszcza model SELinux, ignorując użytkowników, role i zaawansowane ustawienia wrażliwości. Istnieje tylko jeden użytkownik SELinux (u), dwie podstawowe role (r dla podmiotów i object_r dla obiektów), a ustawienie czułości zawsze wynosi s0. Kategorie decydują o izolacji danych.

Porównanie z AppArmor i innymi LSM-ami

W wielu dyskusjach nieuchronnie pojawia się porównanie SELinux i AppArmor , ponieważ oba są modułami bezpieczeństwa Linuksa i oferują adresy MAC. Jednak ich podejście jest zupełnie inne i warto to zrozumieć przed wyborem jednego lub drugiego dla swojego środowiska.

SELinux definiuje politykę skoncentrowaną na obiektach i ich typach: każdemu obiektowi w systemie (plikom, procesom, gniazdom, portom, urządzeniom, komputerom IPC itp.) przypisana jest etykieta. Decyzje o dostępie podejmowane są na podstawie kontekstów podmiotu i obiektu, niezależnie od dokładnej ścieżki dostępu do pliku. Dzięki temu system jest bardziej stabilny w obliczu zmian struktury katalogów lub alternatywnych widoków systemu plików (chroot, kontenery, montowanie powiązań itp.).

Z kolei AppArmor stosuje politykę skoncentrowaną na zadaniach i ścieżkach. Definiuje profile dla każdego programu, określając, do których ścieżek plików, portów itp. ma on dostęp i jakie uprawnienia mu przysługują. Jest bardziej intuicyjny w konfiguracji i ogólnie bardziej przyjazny dla administratorów, którzy nie chcą stać się ekspertami w SELinux, ale jego kontrola jest nieco mniej szczegółowa i bardziej zależna od struktury systemu plików.

Oba systemy opierają się na zasadzie domyślnego blokowania, ale stosują ją inaczej: AppArmor domyślnie blokuje tylko zadania objęte profilami, podczas gdy SELinux, w trybie ścisłym, rozszerza ją na cały system i wszystkie oznaczone obiekty. W rezultacie SELinux zazwyczaj oferuje głębszy poziom ograniczeń , kosztem bardziej rozbudowanej i złożonej polityki.

Praktyczne narzędzia do zarządzania SELinux

Praca z SELinux opiera się na szeregu narzędzi wiersza poleceń, które upraszczają zarządzanie trybami, tagowaniem, wartościami logicznymi i modułami zasad. Choć na pierwszy rzut oka może się to wydawać przytłaczające, kilka narzędzi umożliwia realizację większości codziennych zadań.

Aby wyświetlić kontekst zabezpieczeń plików i procesów, możesz skorzystać z opcji -Z w popularnych poleceniach, takich jak ls, ps czy id. Na przykład, ls -Z Oprócz uprawnień DAC pokaże kontekst SELinux każdego pliku, umożliwiając szybkie sprawdzenie, czy tagowanie jest zgodne z oczekiwaniami.

Polecenie `chcon` („zmień kontekst”) umożliwia ręczną modyfikację całego kontekstu pliku lub tylko jego określonych części (roli, typu, zakresu) za pomocą opcji takich jak `-r`, `-to` i `-l`. Jest to przydatne w przypadku jednorazowych poprawek, ale należy pamiętać, że zmiany mogą zostać utracone, jeśli etykiety zostaną ponownie zastosowane zgodnie z polityką za pomocą narzędzi takich jak `restorecon` lub `fixfiles`.

Narzędzie semanage to prawdziwy scyzoryk w zarządzaniu politykami w czasie wykonywania. Za pomocą różnych podpoleceń można zarządzać trwałymi kontekstami plików (fcontext), mapowaniami logowania między użytkownikami Linuksa i SELinux (login), użytkownikami SELinux i ich rolami (user), oznaczonymi portami (port), wartościami logicznymi, a nawet modułami polityk. Wszystko to bez konieczności ponownej kompilacji całej polityki ze źródeł.

Do sprawdzania i zmiany stanu wartości logicznych – małych przełączników włączających lub wyłączających bloki reguł w ramach polityki – oprócz samej wartości logicznej setsebool używane są polecenia getsebool i setsebool . Typową wartością logiczną jest httpd_enable_homedirs, która po aktywacji umożliwia serwerowi WWW dostęp do katalogów domowych użytkowników (przydatne w przypadku ~user/public_html/).

Wreszcie polecenia takie jak fixfiles umożliwiają wymuszenie całkowitego ponownego oznakowania systemu plików zgodnie ze zdefiniowanymi regułami, a semodule zajmuje się instalowaniem, wyświetlaniem, włączaniem lub wyłączaniem modułów zasad (.pp) pakowanych i dystrybuowanych przez zasady referencyjne lub przez administratora.

Tworzenie i dostosowywanie niestandardowych zasad

Gdy aplikacja nie ma własnego modułu SELinux lub potrzebujesz bardziej szczegółowych ograniczeń, czas zabrać się do pracy i stworzyć niestandardowe zasady . Może to brzmieć skomplikowanie, ale przepływ pracy jest dość dobrze zdefiniowany, jeśli dokładnie przestrzegasz pewnych kroków.

Pierwszym krokiem jest upewnienie się, że odpowiednie obiekty (pliki wykonywalne, katalogi danych, gniazda itp.) są oznaczone odpowiednimi typami. Można to osiągnąć, definiując reguły kontekstu pliku za pomocą ` semanage fcontext` i stosując je za pomocą `restorecon`, używając wyrażeń regularnych obejmujących całe drzewa katalogów.

Następnie system jest zazwyczaj przełączany w tryb permisywny dla danej maszyny (lub, w niektórych przypadkach, dla konkretnej domeny), a aplikacja może działać normalnie, podczas gdy SELinux rejestruje wszystkie polecenia `avc:denified` , które mogłyby wystąpić. Te logi, zazwyczaj analizowane za pomocą narzędzi takich jak audit2allow , służą do wyodrębniania reguł kandydujących.

Zasady referencyjne są zazwyczaj ustrukturyzowane w trzech plikach dla każdej aplikacji: pliku .te zawierającym reguły TE (zezwalaj, typ, typ_domeny itd.), pliku .fc zawierającym reguły kontekstu pliku oraz pliku .if zawierającym interfejsy publiczne, które mogą być ponownie wykorzystywane przez inne moduły. Wszystkie te elementy są kompilowane do modułów .pp za pomocą make i ładowane za pomocą semodule.

Kluczowe jest, aby nie ufać bezkrytycznie wszystkiemu, co sugeruje audit2allow: zazwyczaj jest on bardziej liberalny, niż to konieczne . Najlepiej ręcznie przejrzeć sugerowane reguły, utworzyć nowe typy w razie potrzeby, aby oddzielić dane wrażliwe od nieistotnych, a gdy odrzucona operacja nie jest krytyczna, rozważyć użycie reguł dontaudit, aby zatrzymać rejestrowanie szumów bez udzielania uprawnień.

W środowiskach takich jak SUSE Linux Micro czy Android dostępne są dodatkowe narzędzia (na przykład Udica do generowania zasad kontenerów z opisów JSON), które automatyzują część procesu, szybko dostosowując zasady do konkretnych kontenerów, bez konieczności uczenia się całego języka zasad od podstaw.

Cały ten ekosystem kontekstów, modułowych zasad, wartości logicznych i narzędzi zarządzania sprawia, że ​​SELinux jest niezwykle solidną i elastyczną platformą bezpieczeństwa . Przy początkowym nakładzie pracy, pozwala na bardzo precyzyjne ograniczenie możliwości każdej usługi lub aplikacji, radykalnie wzmacniając powierzchnię ataku systemu przed exploitami, złośliwym oprogramowaniem i błędami ludzkimi.