SELinux

Projekt SELinux nie jest pierwszym projektem w historii naukowców z NSA, związanym z tematem bezpieczeństwa. Naukowcy NSA nie jako pierwsi zauważyli, iż główny nurt systemów operacyjnych nie posiada krytycznych zabezpieczeń wymaganych do wymuszenia kontroli dostępu oraz odseparowania informacji poufnych od wymagań spójności. Efekt jest taki, że większość mechanizmów bezpieczeństwa aplikacji jest wrażliwych na manipulacje i obchodzenie, co pociąga za sobą lawinę konsekwencji...

Wybór Linux'a jako systemu na którym NSA operowała tworząc nowy projekt, nie był przypadkowy. Złożyły się na to dwie główne cechy Linux'a:

rosnąca popularność
środowisko open developement

Intencją NSA było zaprezentowanie funkcjonalności, która może odnieść sukces w głównym nurcie systemów operacyjnych i jednocześnie miałaby szanse przyczynić się do poprawienia bezpieczeństwa powszechnie używanych systemów operacyjnych. W rezultacie w projekcie SELinux zostały zarejestrowane rezultaty kilku wcześniejszych projektów NSA.

Jak zastrzega sobie NSA, praca ich naukowców (nalezy czytać, naukowców sponsorowanych przez NSA) nie miała na celu rozwiązywania istniejących problemów bezpieczeństwa, a SELinux nie jest w żadnej mierze próbą poprawienia słabych punktów bezpieczeństwa w Linux'ie. W trakcie pracy nad projektem, zmiany w Linux'ie objęły jedynie obszary wymagające zmian w celu wprowadzenia nowych mechanizmów.

3 części podarunku od NSA.

1) Jądro - SELinux korzysta z interface'ów LSM (Linux Security Modules). Za ich pomocą realizuje kontrole dostępu podczas pracy użytkowników w systemie. Dla administratora (zgodnie z tym co stwierdza NSA na swojej stronie poświęconej projektowi) SELinux jest łatą, którą należy nałożyć na jądro.

2) Modyfikacje programów - Zmiany w jądrze Linuxa, mimo iż nie miały na celu poprawiania istniejących błędów bezpieczeństwa, wymusiły pewne zmiany. Zmiany te objęły także co ważniejsze dla poprawnego i bezpiecznego działania systemu programy (m.in. ssh, ls, ps, login). W tym przypadku ponownie przy instalacji SELinux'a rola administratora ogranicza się do zaaplikowania łat.

3) Polityka bezpieczeństwa - wraz z systemem Linux jest dostarczona bardzo funkcjonalna, już skonfigurowana i polecana polityka bezpieczeństwa. Polityka bezpieczeństwa jest konfigurowalna i wymaga od administratora zapoznania się ze składnią konfiguracji polityki.

Pare skrótów i pojęć z dziedziny technik implementacji oraz modeli bezpieczeństwa:

DAC - Discretionary access controll
DAC definiuje podstawowe metody kontroli dostępu do obiektów w systemie plików. DAC pozwala użytkownikowi na całkowite ustalenie uprawnień dostępu do swoich zasobów, co oznacza że przez przypadek lub złośliwość można dać dostęp niepowołanym osobom. DAC jest aktualnie używany jako podstawowy model bezpieczeństwa w Linuxsie. W modelu DAC naturalnym zjawiskiem jest dzielenie wszelkiego rodzaju zasobów, jako iż użytkownik definiuje prawa dostępu do tworzonych obiektów. Obiekty użytkownika i procesu domyślnie dziedziczą po nim prawa dostępu.

MAC - Mandatory access control
MAC jest modelem ochrony i zabezpieczania procesów, danych i urządzeń systemowych przed szkodliwym nadużyciem/wykorzystaniem. MAC rozszerza lub zastępuje DAC. Najważniejszą cechą jest to, iż użytkownik nie może w pełni kontrolować dostępu do zasobów, które tworzy. Sposób działania zabezpieczeń systemu (konfigurowalny przez administratora) całkowicie określa dostęp jaki użytkownik systemu może nadać swoim zasobom. Użytkownik nie może nadać mniej restrykcyjnych ograniczeń niż pozwala mu na to administrator.

RBAC - Role-Based Access Control
RBAC jest podejściem do ograniczania dostępu do zasobów systemowych na podstawie roli, jaką uzytkownik pełni w systemie. Jest to nowsze i inne podejście niż MAC i DAC.
RBAC różni się od MAC i DAC. Wcześniej MAC i DAC były jedynymi modelami kontroli dostępu. Jeżeli jakiś nowy model nie było modelem MAC to był kwalifikowany jako DAC i na odwrót, jednak jak pokazały badania RBAC nie należy do żadnego z dwóch modeli.

RBAC można przedstawić na przykładzie organizacji, wewnątrz której role są tworzone dla różnych funkcji. Pracownicy i personel mają przypisane szczególne role i przez przypisanie do tych ról, nabywają uprawnień do wykonywania określonych dla roli czynności.
Ponieważ użytkownicy nie mają przypisanych uprawnień wprost, lecz zyskują je poprzez swoje role, dlatego zarządzanie indywidualnymi użytkownikami staje się jedynie kwestią przypisania użytkownikowi odpowiedniej roli, co upraszcza powszechne operacje takie jak dodawania użytkownika, czy zmieniania przydziału użytkownika.

TE - Type enforcement
W modelu TE każdy obiekt w systemie ma przypisany atrybut bezpieczeństwa. Dla procesów jest to domena, dla pozostałych obiektów jest to typ. TE traktuje wszytkie procesy należące do domeny w taki sam sposób. Identycznie jest z obiektami tego samego typu. Macierze dostępu definiują jaki dostep mają domeny do typów oraz jak domeny mogą wzajemnie oddziaływać z innymi domenami. Natomiast użytkownik ma nadane prawa do operowania w określonych domenach.

Model TE wspomaga silną kontrole nad wykonaniem programu i przejściami pomiędzy domenami. Program, tak jak każdy inny obiekt, ma przydzielony typ, a macierz dostępu TE okresla jakie typy mogą być wykonywane w określonej domenie. Ponadto macierz dostępu TE mówi jakie typy mogą być wykonane aby dostać się do domeny, jako iż domena może być skojarzona ze szczególnym programem dostępowym i opcjonalnie ze szczególnymi programami wspomagającymi i/lub dzielonymi bibliotekami.

Charakterystyka TE jest użyteczna w kojarzeniu uprawnień z konkretnym zbiorem kodu, bazując na jego funkcji i stopniu zaufania kodu. TE pomaga także w ochronie przed wykonywaniem szkodliwego kodu.

ACL - Access control list
ACL jest mechanizmem uzupełniającym model DAC. ACL polega na dodaniu nowych klas dostepu oraz praw dostępu do danego obiektu, w zależności od pewnych aspektów procesu proszącego o dostęp. Tak jak w DAC definiujemy uprawnienia w schemacie UGO, tak w ACL możemy to rozszerzyć o zdefiniowanie praw dla konkretnych użytkowników lub grup.

Lista jest strukturą danych (zazwyczaj tablica) zawierającą wpisy, które określają indywidualne dla użytkownika/grupy prawa do określonego obiektu systemowego (program, proces, plik). Te wpisy są znane jako Access control entries (ACE) w systemach MS Windows i OpenVMS. Każdy dostępny/osiągalny obiekt zawiera identyfikator swojego ACL. Przywileje/uprawnienia określają specyficzne prawa dostępu, takie jak prawa do czytania, pisania, wykonywania. W niektórych implementacjach ACE kontroluje czy użytkownik/grupa może zmieniać ACL obiektu.

MLS - Multi-level security
Jest to zdolność systemu do przenoszenia informacji z różnym wyczuleniem (np. klasyfikacja informacji na różnych poziomach bezpieczeństwa), pozwalania na równoległy dostęp przez użytkowników z różnymi uprawnieniami oraz zapobiegania do pozyskiwania informacji, do której użytkownik nie ma autoryzacji.

Developerzy systemów interpretują MLS jako mechanizm wymuszający ograniczenia na dzielenie się informacjami. System implementuje MLS, jeżeli implementuje mechanizm, który wymusza restrykcje na dzielenie się poufnymi danymi, niezależnie od tego jak efektywne dzielenie informacjami jest.
Na przykładzie firmy możemy to pokazać w taki sposób jakby pracownik na niższym szczeblu mógł przesyłać dokumenty do pracownika na szczeblu wyższym. Natomiast niezależnie od tego co pracownik na wyższym szczeblu chce przekazać pracownikowi na niższym szczeblu, to nie może tego zrobić, nie zależnie od tego co chce przekazać.

Architektura FLASK (Flux Advanced Security Kernel).
System operacyjny zbudowany na architekturze FLASK zapewnia elastyczne wsparcie dla MAC. Każdy podmiot (proces) i obiekt w systemie (plik, port etc.) ma przydzielony zbiór atrybutów bezpieczeństwa, znany jako kontekst bezpieczeństwa. Kontekst bezpieczeństwa zawiera wszytkie atrybuty bezpieczeństwa przypisane konkretnemu podmiotowi lub obiektowi, który jest istotny dla polityki. Zawartość i format kontekstu bezpieczeństwa zależy od modelu/implementacji , zatem kontekst bezpieczeństwa jest interpretowany jedynie przez serwer.

Model bezpieczeństwa w SELinux

SELinux jest systemem implementującym architekturę FLASK, a co za tym idzie realizuje on politykę MAC. Realizowane jest to przy użyciu wybranych modeli bezpieczeństwa. Implementacja przykładowego serwera bezpieczeństwa dla SELinux bazuje na modelu bezpieczeństwa będącym połączeniem modeli RBAC,TE i MLS. SELinux utrzymuje tzw. kontekst bezpieczeństwa składający się z trzech atrybutów bezpieczeństwa: tożsamości, roli i typu. Przy obliczaniu zbioru decyzji dostępu używany jest każdy z trzech składników kontekstu bezpieczeństwa.

TE a SELinux
Model TE w SELinux różni się od oryginału tym, że używa jednego typu atrybutu w kontekście bezpieczeństwa dla procesów i obiektów. Domena jest zwyczajnie typem, który może być powiązany z procesem. Pojedynczy typ może być zarówno użyty jako domena procesu lub jako typ powiązanego obiektu (np. pozycje /proc/pid albo procesu). Pojedyncza macierz dostępu określa jak określone typy mogą wzajemnie oddziaływać z innymi typami w kategoriach uprawnień zdefiniowanych przez architekturę FLASK. (Przykładowa implementacja oraz dokumentacja często korzysta z pojęcia domeny, jednak model TE w SELinux nie rozróżnia wewnętrznie domen od typów).

Kolejną różnicą, między modelem TE w SELinux, a zwykłym TE jest to, iż korzysta z informacji o klasach bezpieczeństwa dostarczonych przez architekturę Flask. Decyzja przejścia lub dostępu w SELinux bazuje na parze typów i na klasie bezpieczeństwa. Polityka bezpieczeństwa może traktować obiekty o tym samym typie, a różnej klasie bezpieczeństwa w różny sposób. (Przykład gniazda TCP od gniazda IP stworzonych przez tę samą domenę).

Trzecią różnicą między modelem TE SELinux a pierwowzorem jest to, iż SELinux nie przypisuje bezpośrednio użytkownikom domen. W zamian SELinux korzysta z modelu RBAC w celu zapewnienia warstwy abstrakcji między użytkownikami a domenami. (patrz RBAC a SELinux)

RBAC a SELinux
Tradycyjny model RBAC upoważnia użytkowników do działania w określonych rolach i przypisuje zbiory uprawnień do każdej roli. Model SELinux RBAC upoważnia każdego użytkownika do zbioru ról i upoważnia każdą role do zbioru domen/typów z modelu TE. Przypisanie uprawnień jest przede wszystkim przełożone na konfigurację TE. Mimo iż takie wykorzystanie RBAC nie wprowadza dodatkowego bezpieczeństwa do ścisłej polityki TE, to pozwala na łatwiejsze sterowanie polityką TE, przez wykorzystanie ról, jako koncepcji wyższego poziomu. To podejście łączy łatwość zarządzania zapewnioną przez model RBAC z drobnoziarnistą ochroną zapewnioną przez model TE.

Tożsamość w SELinux
Z każdym procesem w systemie jest powiązana tożsamość. Zmiany w tożsamości są rygorystycznie kontrolowane i konfiguracja metod postępowania pozwala jedynie określonym programom na zmianę tożsamości. Kiedy użytkownik loguje się, cześć tożsamościowa kontekstu bezpieczeństwa powiązana z jego powłoką będzie odzwierciedlała prawdziwą tożsamość użytkownika. Jakkolwiek zmieniony zostanie UID procesu, jego tożsamość w SELinux pozostaje niezmieniona; kiedy nowy program jest wykonywany część tożsamościowa zostaje zachowana. W ten sposób wszystkie decyzje kontroli dostępu mogą bazować na poprawnej tożsamości, która niejako jest składnikiem kontekstu bezpieczeństwa.

Działania każdego użytkownika są ograniczone przez RBAC. Użytkownicy mają przypisane zbiory ról, które mogą wykonywać. Przejście między rolami jest w pełni kontrolowane. Mimo iż nie jest to ściśle konieczne, polityka bezpieczeństwa została skonfigurowana żeby ograniczyć przejścia między rolami do pojawiania się jedynie jako efekt działania programów wymagających uwierzytelnienia użytkownika. W ten sposób zapewniono, że zmiana ról może nastąpić jedynie za wyłączną zgodą użytkownika, a nie poprzez wykonanie złośliwego programu.

Mówiąc o tożsamości należy wspomnieć, iż reguły dostępu w SELinux współdziałają ze standardowym modelem uprawnień UGO (User, Goup, Others) systemu Uniks. SELinux względem modelu UGO jedynie ogranicza uprawnienia do podejmowanych w systemie działań. W przypadku braku polityki bezpieczeństwa lub konfiguracji, która na zbyt wiele pozwala, system zawsze zostanie ograniczony przez standardowy model UGO.

Zainstalowane, skonfigurowane. Co się tam dzieje w trakcie działania??

SELinux standardowo operuje na SIDach (identyfikatory bezpieczeństwa). SID jest integerem który jest przez serwer bezpieczeństwa odwzorowywany do kontekstu bezpieczeństwa w trakcie wykonania. SIDy są niestałymi lokalnymi identyfikatorami i muszą być tłumaczone do kontekstu bezpieczeństwa, w celu oznaczania obiektów. Mały zbiór SIDów jest zarezerwowany dla inicjalizacji systemu lub predefiniowanych obiektów. SIDy jądra nie są eksportowane do przestrzeni użytkownika.

Decyzje dostepu określają czy wyrażona jest zgoda dla danej pary SIDów i klasy bezpieczeństwa. Każda klasa obiektu ma zbiór przypisanych uprawnień zdefiniowanych, aby kontrolować operacje na obiektach tej klasy. Te zbiory uprawnień są reprezentowane jako mapy bitowe zwane wektorami dostępu.

Podejmowanie decyzji w SELinux

Interface i przykładowe wywołanie w celu uzyskania etykiety bezpieczeństwa. Parametry wejściowe to SID wywołującego, SID obiektu powiązanego (np. rodzimy katalog) oraz klasa nowego obiektu. Zwracany jest SID nowego obiektu.

Interface do pozyskiwania decyzji dostępu od serwera bezpieczeństwa. Parametry wejściowe to para SIDów, klasa obiektu, i zbiór uprawnień o które proces zabiega. Zwracane są przyznane uprawnienia.

Decyzje o etykietowaniu, także określane jako decyzje przejścia, określają atrybuty bezpieczeństwa dla nowego podmiotu lub obiektu. Prośba o decyzje przejścia dla procesu jest kierowana w momencie, gdy program jest wykonywany. Dla obiektu ma to miejsce w momencie tworzenia nowego obiektu. Dla każdego z przypadków, pod uwagę brane są dwa SIDy i w obu jednym z nich jest bieżący SID procesu działającego, zaś drugim jest odpowiednio SID programu, który ma być wykonany, lub SID obiektu powiązanego z nowo tworzonym (np. katalog rodzimy dla tworzonych plików). Decyzja jest wydawana na podstawie bieżącego SID procesu oraz SID programu. Użycie nowej etykiety musi być zatwierdzone przez decyzje dostępowe, w przeciwnym przypadku operacja się nie powiedzie.

Kiedy jest wymagana decyzja bezpieczeństwa, para SIDów (zazwyczaj SID procesu i SID obiektu) oraz klasa bezpieczeństwa obiektu, są przekazywane do serwera bezpieczeństwa. Klasa bezpieczeństwa obiektu wskazuje na typ obiektu (proces, plik, katalog, gniazdo TCP etc.). Serwer bezpieczeństwa przegląda kontekst bezpieczeństwa dla SIDów. Następnie podejmuje decyzje bazując na atrybutach wewnątrz kontekstu i klasie bezpieczeństwa obiektu. Serwer bezpieczeństwa zapewnia dwa główne typy decyzji. Są to: decyzje o etykietowaniu obiektów (przydzielaniu im atrybutów bezpieczeństwa) oraz decyzje dostępowe.

Konfiguracja polityki bezpieczeństwa

Przykłądowe table konfigurowalnych uprawnień dla różnych obiektów systemowych
Na stronie NSA, w dokumencie o wdzięcznej nazwie: Integrating Flexible Support for Security Policies into the Linux Operating System, znajdują się tabele, pokazujące zakres operacji dla obiektów systemowych, do których można zdefiniować dostęp.
kontrola procesów
kontrola plików
kontrola gniazd
W SELinux, polityka bezpieczeństwa, czyli wszytko co wchodzi w użyty model bezpieczeństwa, jest konfigurowalne przez administratora systemu.
Dla celów konfiguracji został przez NSA stworzony deklaratywny język. Co bardziej zainteresowanych odsyłam do artykułu: Configuring the SELinux Policy, a w szczególności do paragrafów:
Język polityki i przykładowa konfiguracja.
Budowa i wprowadzenie polityki.

Administrator systemu przy tworzeniu polityki bezpieczeństwa ma możliwośc:

Definiowania reguł TE dla przejść procesów między domenami.
Definiowania reguł TE dla wektorów dostępu.
Ustalania reguł domyślnych, w przypadku braku pasującej reguły dla przejśc procesów lub wektorów bezpieczeństwa
Tworzenia ról dla modelu RBAC.
Tworzenia domen i definiowania dla nich praw dostępu
Określania dostępu ról do domen.

Przykładowy fragment konfiguracji

Konfiguracja insmod.

To jest fragment konfiguracji polityki bezpieczeństwa, która pozwala domenie administratora (sysadm_t) na wykonywanie programu insmod (każdy powinien wiedzieć co robi ten program). Program insmod jest etykietowany typem insmod_exec_t i wykonuje się w domenie insmod_t.
1 - pozwolenie domenie sysadm_t na wykonywanie programu insmod.
2 - pozwolenie na przejście z domeny sysadm_t do domeny insmod_t.
3 - pozwolenie na wejście programowi insmod do domeny insmod_t i wykonanie kodu insmod w tej domenie.
4 - pozwolenie na odziedziczenie i użycie przez domenę insmod_t deskryptorów plików.
5 - pozwolenie domenie insmod_t na użycie sys_module.
6 - pozwolenie insmod_t na wysłanie sygnału SIGCHILD do sysadm_t.

Z tego małego fragmentu konfiguracji polityki oczywiste jest że elastyczność MAC pociąga za sobą skomplikowanie zarządzania polityką bezpieczeństwa. Tworzenie i obsługiwanie konfiguracji, aby ta spełniała wymagania bezpieczeństwa oraz weryfikacja jej poprawności może być dużym wyzwaniem. W celu umożliwienia powszechnego użycia została stworzony domyślna konfiguracja, umożliwiająca korzystanie z SELinux użytkownikom bez doświadczenia w dziedzinie bezpieczeństwa.

Przeciwdziałanie błędowi przepełnienia bufora.

W SELinux nie ma zaimplementowanego mechanizmu bezpośredniego zapobiegania błędowi przepełnienia bufora. W żaden sposób system nie jest chroniony przed wystąpieniem tego błędu. SELinux nie ma wbudowanego żadnego z wymienionych mechanizmów. Siłą bezpieczeństwa SELinux jest jego model bezpieczeństwa oraz fakt, że ilość domen przypisana do każdej roli jest minimalną wymaganą w celu wykonywania funkcji. Tak samo ma się sprawa z domenami, każda z domen jest ograniczona do minimum uprawnień potrzebnych do jej działania.

Typowe użycie przepełnienia bufora jest używane w celu odpalenia powłoki lub innego programu. Pod SELinux, tylko określone domeny są uprawnione do zrobienia tego. Jeżeli polityka bezpieczeństwa nie pozwala domenie procesu na wykonywanie programów, nastąpi złamanie zasad polityki i atak zostanie zatrzymany. Nawet, jeśli proces może wykonać inny program, to tylko programy o określonym typie mogą być uruchomione w domenie danego procesu.

Restrykcje dotyczą także uprzywilejowanych procesów jak i root'a. Wszystkie procesy systemowe są ustawione, aby działać każdy w swojej domenie. Te domeny posiadają jedynie uprawnienia konieczne do wykonywania zadań przeznaczonych programom w tej domenie. Na przykład, jeżeli program "alamakota" zostanie zaatakowany przy użyciu przepełnienia bufora, polityka zapobiegnie wykonaniu innego programu. W dodatku, jeżeli atakującemu uda się wrzucić kod do przestrzeni procesu, to kod ten będzie miał jedynie dostęp do obiektów, do których polityka dopuszcza "alamakota".

Problem pojawia się, jeżeli polityka pozwala domenie procesu na dostęp do plików udostępniających pamięć systemu, wtedy system może zostać zaatakowany. Dlatego, też ważna jest prawidłowa konfiguracja polityki, szczególnie w zakresie domen mających dostęp do pamięci systemu. W SELinux domyślnie takie uprawnienia mają tylko domeny programów wykonywanych przez klogd i xserwer.

Umiejętnie skonfigurowany SELinux zapewnia bardzo efektywną ochrone przeciw nadużyciu przepełnienia bufora.

Linux a SELinux
Bezpieczeństwo niezmodyfikowanego Linux'a zależy od poprawności jądra oraz wszystkich uprzywilejowanych aplikacji oraz każdej z ich konfiguracji. Problem w dowolnym z regionów tychże może spowodować wystawienie całego systemu na działanie zewnętrzne. W przypadku SELinux problemy z poprawnością zabezpieczeń lub konfiguracji aplikacji może pozwolić jedynie na ujawnienie programów użytkownika, jednakże nie powoduje to zagrożenia dla wyżej wymienionych i dla bezpieczeństwa całego systemu.

SELinux nie jest systemem bezpiecznym.
SELinux zawiera jedynie bardzo mały zbiór atrybutów definiujących bezpieczny system (m.in. przewijająca się w tej czy innej formie obowiązkową kontrolę dostępu). Jak NSA powtarza, kiedy tylko się da, SELinux jest jedynie prototypem mającym demonstrować konieczne funkcje kontrolne w nowoczesnym systemie operacyjnym, a co za tym idzie jest mało prawdopodobne, aby spełniał jakąkolwiek sensowną definicje bezpiecznego systemu. Technologia stworzona, przez NSA może być wartościowa dla ludzi tworzących bezpieczne systemy i oprogramowanie.

SELinux w praktycznym zastosowaniu
Mimo, iż SELinux miał mieć charakter ściśle naukowy, to uznanie, z jakim się spotkał spowodowało, iż technologia ta zdobyła sobie dużą popularność w praktycznych zastosowaniach. Aktualnie większość z dostępnych dystrybucji Linuxa korzysta już z tej technologii lub jest przystosowana do jej obsługiwania. Każdy z nas jest w stanie skorzystać z tej technologii, zapewniając swojemu komputerowi więcej bezpieczeństwa przed niepowołanym dostępem z zewnątrz.

Źródła:
http://www.nsa.gov/selinux/
http://www.nsa.gov/selinux/info/docs.cfm
http://www.nsa.gov/selinux/index.cfm
http://www.nsa.gov/selinux/info/faq.cfm
http://www.nsa.gov/selinux/papers/policy2/t1.html
http://www.nsa.gov/selinux/papers/freenix01/freenix01.html
http://en.wikipedia.org/wiki/Selinux
http://en.wikipedia.org/wiki/FLASK
http://en.wikipedia.org/wiki/Access_control_list
http://en.wikipedia.org/wiki/Role-Based_Access_Control

Autor: Piotr Kacperski