Linux ze zwiększonymi zabezpieczeniami — Security-Enhanced Linux

Linux ze zwiększonymi zabezpieczeniami
SELinux logo.svg
SELinux admin.png
GUI administratora SELinux w Fedorze 8
Pierwotny autor (autorzy) NSA i Red Hat
Deweloper(zy) czerwony kapelusz
Pierwsze wydanie 22 grudnia 2000 ; 20 lat temu ( 2000-12-22 )
Wersja stabilna
3.2 / 4 marca 2021 ; 5 miesięcy temu ( 04.03.2021 )
Magazyn Edytuj to na Wikidata
Napisane w C
System operacyjny Linux
Rodzaj Bezpieczeństwo, moduły bezpieczeństwa Linux (LSM)
Licencja GNU GPL
Strona internetowa selinuxproject .org , https://www.nsa.gov/what-we-do/research/selinux/

Security-Enhanced Linux ( SELinux ) to moduł bezpieczeństwa jądra systemu Linux , który zapewnia mechanizm obsługi zasad bezpieczeństwa kontroli dostępu , w tym obowiązkowych kontroli dostępu (MAC).

SELinux to zestaw modyfikacji jądra i narzędzi przestrzeni użytkownika, które zostały dodane do różnych dystrybucji Linuksa . Jego architektura dąży do oddzielenia egzekwowania decyzji dotyczących bezpieczeństwa od polityki bezpieczeństwa i usprawnia ilość oprogramowania zaangażowanego w egzekwowanie polityki bezpieczeństwa. Kluczowe koncepcje leżące u podstaw SELinux można prześledzić w kilku wcześniejszych projektach Agencji Bezpieczeństwa Narodowego Stanów Zjednoczonych (NSA).

Przegląd

NSA Security-enhanced Linux Team opisuje NSA SELinux jako

zestaw poprawek do jądra Linux i narzędzi zapewniających silną, elastyczną, obowiązkową architekturę kontroli dostępu (MAC) do głównych podsystemów jądra. Zapewnia ulepszony mechanizm wymuszania separacji informacji w oparciu o wymagania dotyczące poufności i integralności, który umożliwia eliminację zagrożeń manipulacji i ominięcie mechanizmów bezpieczeństwa aplikacji oraz umożliwia ograniczenie szkód, które mogą być spowodowane przez złośliwe lub wadliwe aplikacje. Zawiera zestaw przykładowych plików konfiguracyjnych zasad bezpieczeństwa zaprojektowanych w celu spełnienia wspólnych, ogólnych celów bezpieczeństwa.

Jądro Linux integrujące SELinux wymusza obowiązkowe zasady kontroli dostępu, które ograniczają programy użytkownika i usługi systemowe, a także dostęp do plików i zasobów sieciowych. Ograniczenie uprawnień do minimum wymaganego do pracy zmniejsza lub eliminuje zdolność tych programów i demonów do powodowania szkód, jeśli są wadliwe lub naruszone (na przykład przez przepełnienie bufora lub błędną konfigurację). Ten mechanizm ograniczania działa niezależnie od tradycyjnych ( uznaniowych ) mechanizmów kontroli dostępu Linuksa . Nie ma pojęcia o "root" superużytkownika i nie podziela dobrze znanych wad tradycyjnych mechanizmów bezpieczeństwa Linuksa, takich jak zależność od plików binarnych setuid / setgid .

Bezpieczeństwo „niezmodyfikowanego” systemu Linux (system bez SELinux) zależy od poprawności jądra, wszystkich uprzywilejowanych aplikacji i każdej z ich konfiguracji. Usterka w którymkolwiek z tych obszarów może doprowadzić do kompromitacji całego systemu. W przeciwieństwie do tego, bezpieczeństwo "zmodyfikowanego" systemu (opartego na jądrze SELinux) zależy przede wszystkim od poprawności jądra i jego konfiguracji polityki bezpieczeństwa. Chociaż problemy z poprawnością lub konfiguracją aplikacji mogą pozwolić na ograniczony dostęp do poszczególnych programów użytkownika i demonów systemowych, niekoniecznie stanowią zagrożenie dla bezpieczeństwa innych programów użytkownika i demonów systemowych lub bezpieczeństwa systemu jako całości.

Z perspektywy purist, SELinux stanowi hybrydę koncepcje i możliwości płynące z kontroli dostępu, obowiązkowe obowiązkowych kontroli integralności , Role-Based Access Control (RBAC) oraz architektury egzekwowania typu . Narzędzia innych firm umożliwiają tworzenie różnych polityk bezpieczeństwa.

Historia

Najwcześniejsze prace ukierunkowane na standaryzację podejścia zapewniającego obowiązkową i uznaniową kontrolę dostępu (MAC i DAC) w środowisku obliczeniowym UNIX (dokładniej POSIX) można przypisać grupie roboczej Trusted UNIX (TRUSIX) Narodowej Agencji Bezpieczeństwa , która spełniła od 1987 do 1991 i opublikował jedną Tęczową Księgę (nr 020A) oraz stworzył formalny model i związany z nim prototyp dowodów ewaluacyjnych (nr 020B), który ostatecznie nie został opublikowany.

SELinux został zaprojektowany, aby zademonstrować wartość obowiązkowych kontroli dostępu społeczności Linuksa i jak można je dodać do Linuksa. Pierwotnie łatki tworzące SELinux musiały być jawnie nałożone na źródła jądra Linux; SELinux został włączony do głównej linii jądra Linuksa w serii 2.6 jądra Linuksa.

NSA, pierwotny główny twórca SELinux, wydał pierwszą wersję dla społeczności programistów open source na licencji GNU GPL 22 grudnia 2000 roku. Oprogramowanie zostało włączone do głównego jądra Linuksa 2.6.0-test3, wydanego 8 sierpnia 2003 roku Inni znaczący współpracownicy to Red Hat , Network Associates , Secure Computing Corporation , Tresys Technology i Trusted Computer Solutions. Eksperymentalne porty KOLBY realizacji / TE zostały udostępnione za pośrednictwem TrustedBSD Projekt dla FreeBSD i Darwin systemów operacyjnych.

Linux z ulepszonymi zabezpieczeniami implementuje Flux Advanced Security Kernel (FLASK). Takie jądro zawiera komponenty architektoniczne prototypowane w systemie operacyjnym Fluke . Zapewniają one ogólną obsługę wymuszania wielu rodzajów obowiązkowych zasad kontroli dostępu, w tym zasad opartych na koncepcjach wymuszania typu , kontroli dostępu opartej na rolach i wielopoziomowych zabezpieczeniach . Z kolei FLASK został oparty na DTOS, rozproszonym zaufanym systemie operacyjnym wywodzącym się z systemu Mach, a także na Trusted Mach, projekcie badawczym firmy Trusted Information Systems, który miał wpływ na zaprojektowanie i wdrożenie systemu DTOS.

Użytkownicy, polityki i konteksty bezpieczeństwa

Użytkownicy i role SELinux nie muszą być powiązane z rzeczywistymi użytkownikami i rolami systemu. Każdemu bieżącemu użytkownikowi lub procesowi SELinux przypisuje trzyciągowy kontekst składający się z nazwy użytkownika, roli i domeny (lub typu). Ten system jest bardziej elastyczny niż zwykle jest to wymagane: z reguły większość prawdziwych użytkowników ma tę samą nazwę użytkownika SELinux, a cała kontrola dostępu jest zarządzana przez trzeci tag, domenę. Okoliczności, w których proces jest dozwolony do określonej domeny, należy skonfigurować w zasadach. Polecenie runconpozwala na uruchomienie procesu w wyraźnie określonym kontekście (użytkownik, rola i domena), ale SELinux może odmówić przejścia, jeśli nie jest to zatwierdzone przez politykę.

Pliki, porty sieciowe i inny sprzęt również mają kontekst SELinux, składający się z nazwy, roli (rzadko używanej) i typu. W przypadku systemów plików mapowanie między plikami a kontekstami bezpieczeństwa nazywa się etykietowaniem. Etykietowanie jest zdefiniowane w plikach zasad, ale można je również dostosować ręcznie bez zmiany zasad. Typy sprzętu są dość szczegółowe, na przykład bin_t(wszystkie pliki w folderze /bin) lub postgresql_port_t(port PostgreSQL, 5432). Kontekst SELinux dla zdalnego systemu plików można jawnie określić podczas montowania.

SELinux dodaje -Zprzełącznik do poleceń powłoki ls, psoraz kilka innych, pozwalając kontekście zabezpieczeń plików lub procesu widać.

Typowe reguły polityki składają się na przykład z wyraźnych uprawnień, na przykład domen, które użytkownik musi posiadać, aby wykonać określone działania z danym celem (odczyt, wykonanie lub, w przypadku portu sieciowego, powiązanie lub połączenie) i tak dalej. Możliwe są również bardziej złożone mapowania, obejmujące role i poziomy bezpieczeństwa.

Typowe zasady składają się z pliku mapowania (etykietowania), pliku reguł i pliku interfejsu, które definiują przejście domeny. Te trzy pliki muszą być skompilowane razem z narzędziami SELinux, aby utworzyć pojedynczy plik polityki. Wynikowy plik polityki można załadować do jądra, aby był aktywny. Zasady ładowania i rozładowywania nie wymagają ponownego uruchomienia. Pliki strategii są albo napisane ręcznie, albo mogą być generowane z bardziej przyjaznego dla użytkownika narzędzia do zarządzania SELinux. Zwykle są najpierw testowane w trybie zezwalającym, w którym naruszenia są rejestrowane, ale dozwolone. audit2allowNarzędzie może być wykorzystywane później do wyprodukowania dodatkowych reguł, które rozciągają się na politykę, aby wszystkie uzasadnione działania aplikacji jest ograniczony.

Cechy

Funkcje SELinux obejmują:

  • Czyste oddzielenie polityki od egzekwowania
  • Dobrze zdefiniowane interfejsy polityk
  • Obsługa aplikacji odpytujących o zasady i wymuszających kontrolę dostępu (na przykład crond uruchamiające zadania w odpowiednim kontekście)
  • Niezależność określonych polityk i języków polityk
  • Niezależność od określonych formatów i treści etykiet zabezpieczających
  • Indywidualne etykiety i kontrolki dla obiektów i usług jądra
  • Wsparcie dla zmian polityki
  • Oddzielne środki ochrony integralności systemu (typ domeny) i poufności danych ( bezpieczeństwo wielopoziomowe )
  • Elastyczna polityka
  • Kontrola nad inicjalizacją i dziedziczeniem procesów oraz wykonywaniem programu
  • Kontrola nad systemami plików, katalogami, plikami i otwartymi deskryptorami plików
  • Kontrola nad gniazdami, wiadomościami i interfejsami sieciowymi
  • Kontrola nad wykorzystaniem „zdolności”
  • Buforowane informacje o decyzjach dostępu poprzez Access Vector Cache (AVC)
  • Zasada odmowy domyślnej (wszystko, co nie zostało wyraźnie określone w zasadach, jest niedozwolone)

Realizacje

SELinux został zaimplementowany w systemie Android od wersji 4.3.

Wśród darmowych, wspieranych przez społeczność dystrybucji Linuksa, Fedora była jednym z pierwszych użytkowników, w tym domyślnie wspierała ją od Fedory Core 2. Inne dystrybucje obejmują wsparcie dla niej, takie jak Debian od wersji 9 Stretch i Ubuntu od 8.04 Hardy Heron. Od wersji 11.1, openSUSE zawiera "podstawowe włączenie" SELinux. SUSE Linux Enterprise 11 zawiera SELinux jako „przegląd technologii”.

SELinux jest popularny w systemach opartych na kontenerach linuxowych , takich jak CoreOS Container Linux i rkt. Jest to przydatne jako dodatkowa kontrola bezpieczeństwa, która pomaga w dalszym egzekwowaniu izolacji między wdrożonymi kontenerami a ich hostem.

SELinux jest dostępny od 2005 roku jako część Red Hat Enterprise Linux (RHEL) w wersji 4 i wszystkich przyszłych wydaniach. Obecność ta znajduje również odzwierciedlenie w odpowiednich wersjach CentOS i Scientific Linux . Obsługiwana polityka w RHEL4 jest polityką ukierunkowaną, która ma na celu maksymalną łatwość użytkowania i dlatego nie jest tak restrykcyjna, jak mogłaby być. Planuje się, że przyszłe wersje RHEL będą miały więcej celów w docelowej polityce, co będzie oznaczać bardziej restrykcyjną politykę.

Użyj scenariuszy

SELinux może potencjalnie kontrolować, jakie działania system umożliwia każdemu użytkownikowi, procesowi i demonowi, z bardzo precyzyjnymi specyfikacjami. Służy do ograniczania demonów, takich jak silniki baz danych lub serwery internetowe, które mają jasno określone prawa dostępu do danych i aktywności. Ogranicza to potencjalną szkodę ze strony ograniczonego demona, który zostaje skompromitowany.

Narzędzia wiersza polecenia obejmują: chcon, restorecon, restorecond, runcon, secon, fixfiles, setfiles, load_policy, booleans, getsebool, setsebool, togglesebool setenforce, semodule, postfix-nochroot, check-selinux-installation, semodule_package, checkmodule, selinux-config-enforcing, selinuxenabled, iselinux-policy-upgrade

Przykłady

Aby wprowadzić SELinux w tryb wymuszania:

$ sudo setenforce 1

Aby sprawdzić status SELinux:

$ getenforce

Porównanie z AppArmor

SELinux reprezentuje jedno z kilku możliwych podejść do problemu ograniczania działań, które może podjąć zainstalowane oprogramowanie. Inną popularną alternatywą jest AppArmor i jest dostępna na platformach opartych na SUSE Linux Enterprise Server (SLES), openSUSE i Debian . AppArmor został opracowany jako składnik nieistniejącej już platformy Immunix Linux . Ponieważ AppArmor i SELinux radykalnie różnią się od siebie, stanowią odrębne alternatywy dla kontroli oprogramowania. Podczas gdy SELinux na nowo wymyśla pewne koncepcje, aby zapewnić dostęp do bardziej wyrazistego zestawu opcji polityki, AppArmor został zaprojektowany tak, aby był prosty, poprzez rozszerzenie tej samej semantyki administracyjnej używanej w DAC do obowiązkowego poziomu kontroli dostępu.

Istnieje kilka kluczowych różnic:

  • Jedną z ważnych różnic jest to, że AppArmor identyfikuje obiekty systemu plików według nazwy ścieżki zamiast i-węzła. Oznacza to, że na przykład plik, który jest niedostępny, może stać się dostępny w AppArmor po utworzeniu do niego twardego łącza, podczas gdy SELinux odmówi dostępu za pośrednictwem nowo utworzonego twardego łącza.
    • W rezultacie można powiedzieć, że AppArmor nie jest systemem egzekwowania typów , ponieważ pliki nie są przypisane do typu; zamiast tego są jedynie przywoływane w pliku konfiguracyjnym.
  • SELinux i AppArmor różnią się również znacznie sposobem administrowania i integracją z systemem.
  • Ponieważ stara się odtworzyć tradycyjne sterowanie DAC z egzekwowaniem na poziomie MAC, zestaw operacji AppArmor jest również znacznie mniejszy niż te dostępne w większości implementacji SELinux. Na przykład zestaw operacji AppArmor składa się z: odczytu, zapisu, dołączania, wykonywania, blokowania i łączenia. Większość implementacji SELinux będzie obsługiwać większą liczbę rzędów operacji. Na przykład SELinux zazwyczaj obsługuje te same uprawnienia, ale zawiera również kontrolki dla mknod, wiązanie z gniazdami sieciowymi, niejawne korzystanie z możliwości POSIX, ładowanie i rozładowywanie modułów jądra, różne sposoby dostępu do pamięci współdzielonej itp.
  • W AppArmor nie ma kontrolek do kategorycznego ograniczania możliwości POSIX. Ponieważ obecna implementacja możliwości nie zawiera pojęcia podmiotu dla operacji (tylko aktor i operacja), zwykle zadaniem warstwy MAC jest zapobieganie uprzywilejowanym operacjom na plikach poza wymuszoną sferą kontroli aktora (tj. „Sandbox” ). AppArmor może zapobiec zmianie własnych zasad i zapobiec montowaniu/odmontowywaniu systemów plików, ale nie robi nic, aby uniemożliwić użytkownikom wyjście poza ich zatwierdzone obszary kontroli.
    • Na przykład zmiana właściciela lub uprawnień do niektórych plików może być korzystna dla pracowników działu pomocy, nawet jeśli nie są ich właścicielami (na przykład w udziale plików działu). Administrator nie chce dawać użytkownikowi (użytkownikom) uprawnień roota na skrzynce, więc daje im CAP_FOWNERlub CAP_DAC_OVERRIDE. W ramach SELinux administrator (lub dostawca platformy) może skonfigurować SELinux tak, aby odmawiał wszystkim możliwości nieograniczonym użytkownikom, a następnie tworzył ograniczone domeny, do których pracownik mógł przejść po zalogowaniu, taką, która może korzystać z tych możliwości, ale tylko na plikach odpowiedni typ.
  • AppArmor nie ma pojęcia o wielopoziomowym bezpieczeństwie, dlatego nie ma dostępnej twardej egzekucji BLP ani Biba .
  • Konfiguracja AppArmor odbywa się wyłącznie przy użyciu zwykłych plików płaskich. SELinux (domyślnie w większości implementacji) używa kombinacji płaskich plików (używanych przez administratorów i programistów do pisania polityki czytelnej dla człowieka przed jej skompilowaniem) i rozszerzonych atrybutów.
  • SELinux obsługuje koncepcję "zdalnego serwera polityk" (konfigurowanego przez /etc/selinux/semanage.conf) jako alternatywnego źródła konfiguracji polityk. Centralne zarządzanie AppArmor jest zwykle znacznie skomplikowane, ponieważ administratorzy muszą decydować, czy narzędzia do wdrażania konfiguracji mają być uruchamiane jako root (aby umożliwić aktualizowanie zasad), czy konfigurowane ręcznie na każdym serwerze.

Podobne systemy

Izolację procesów można również osiągnąć za pomocą mechanizmów takich jak wirtualizacja ; OLPC projekt, na przykład, w swojej pierwszej implementacji piaskownicy poszczególne aplikacje w lekkich Vservers . Ponadto NSA zaadoptowała niektóre koncepcje SELinuksa w systemie Android z ulepszonym zabezpieczeniem .

General Dynamics buduje i dystrybuuje PitBull Trusted Operating System, rozszerzenie wielopoziomowego bezpieczeństwa (MLS) dla Red Hat Enterprise Linux .

Zobacz też

Bibliografia

Zewnętrzne linki