Koncepcje SELinux

Przejrzyj tę stronę, aby zapoznać się z koncepcjami SELinux.

Obowiązkowa kontrola dostępu

Security Enhanced Linux (SELinux) to obowiązkowy system kontroli dostępu (MAC) dla systemu operacyjnego Linux. Jako system MAC różni się od znanego systemu Linux arbitralnej kontroli dostępu (DAC). W systemie DAC istnieje koncepcja własności, zgodnie z którą właściciel określonego zasobu kontroluje powiązane z nim uprawnienia dostępu. Jest to na ogół nieprecyzyjne i podlega niezamierzonej eskalacji uprawnień. Jednak system MAC konsultuje się z organem centralnym w celu podjęcia decyzji o wszystkich próbach dostępu.

SELinux został zaimplementowany jako część frameworku Linux Security Module (LSM), który rozpoznaje różne obiekty jądra i wykonywane na nich wrażliwe operacje. W punkcie, w którym każda z tych akcji zostałaby wykonana, wywoływana jest funkcja przechwytująca LSM w celu określenia, czy akcja powinna być dozwolona na podstawie informacji o niej przechowywanych w nieprzezroczystym obiekcie bezpieczeństwa. SELinux zapewnia implementację tych zaczepów i zarządzanie tymi obiektami bezpieczeństwa, które w połączeniu z własną polityką określają decyzje dotyczące dostępu.

Wraz z innymi środkami bezpieczeństwa Androida, polityka kontroli dostępu Androida znacznie ogranicza potencjalne uszkodzenia zainfekowanych komputerów i kont. Korzystanie z narzędzi, takich jak uznaniowa i obowiązkowa kontrola dostępu w systemie Android, zapewnia strukturę zapewniającą działanie oprogramowania tylko na minimalnym poziomie uprawnień. Łagodzi to skutki ataków i zmniejsza prawdopodobieństwo nadpisania lub nawet transmisji danych przez błędne procesy.

W systemie Android 4.3 i nowszym SELinux zapewnia obowiązkowy parasol kontroli dostępu (MAC) nad tradycyjnymi środowiskami arbitralnej kontroli dostępu (DAC). Na przykład oprogramowanie musi zazwyczaj działać jako konto użytkownika root, aby móc pisać na surowych urządzeniach blokowych. W tradycyjnym środowisku Linux opartym na DAC, jeśli użytkownik root zostanie skompromitowany, może on zapisywać na każdym surowym urządzeniu blokowym. Jednak SELinux może być używany do etykietowania tych urządzeń, dzięki czemu proces, któremu przypisano uprawnienia roota, może zapisywać tylko te, które są określone w powiązanej polityce. W ten sposób proces nie może nadpisywać danych i ustawień systemowych poza określonym surowym urządzeniem blokowym.

Zobacz Przypadki użycia , aby uzyskać więcej przykładów zagrożeń i sposobów ich rozwiązywania za pomocą SELinux.

Poziomy egzekwowania

SELinux może być zaimplementowany w różnych trybach:

• Tolerancyjny - polityka bezpieczeństwa SELinux nie jest egzekwowana, tylko rejestrowana.
• Wymuszanie — polityka bezpieczeństwa jest egzekwowana i rejestrowana. Błędy pojawiają się jako błędy EPERM.

Ten wybór jest binarny i określa, czy polityka podejmuje działania, czy tylko pozwala zebrać potencjalne błędy. Permisywny jest szczególnie przydatny podczas implementacji.

Rodzaje, atrybuty i zasady

Android opiera się na składniku Type Enforcement (TE) SELinux dla swoich zasad. Oznacza to, że wszystkie obiekty (takie jak plik, proces lub gniazdo) mają skojarzony z nimi typ . Na przykład domyślnie aplikacja będzie miała typ untrusted_app . W przypadku procesu jego typ jest również określany jako jego domena . Możliwe jest opisanie typu jednym lub wieloma atrybutami . Atrybuty są przydatne do jednoczesnego odwoływania się do wielu typów.

Obiekty są mapowane na klasy (np. plik, katalog, dowiązanie symboliczne, gniazdo), a różne rodzaje dostępu dla każdej klasy są reprezentowane przez uprawnienia . Na przykład istnieje uprawnienie open dla file klasy . Chociaż typy i atrybuty są regularnie aktualizowane w ramach zasad Android SELinux, uprawnienia i klasy są definiowane statycznie i rzadko aktualizowane w ramach nowej wersji systemu Linux.

Reguła polityki ma postać: allow source target : class permissions ; gdzie:

• Źródło — typ (lub atrybut) podmiotu reguły. Kto prosi o dostęp?
• Cel — typ (lub atrybut) obiektu. Do czego żąda się dostępu?
• Klasa — rodzaj obiektu (np. plik, gniazdo), do którego uzyskuje się dostęp.
• Uprawnienia — wykonywana operacja (lub zestaw operacji) (np. odczyt, zapis).

Przykładem reguły jest:

allow untrusted_app app_data_file:file { read write };

Oznacza to, że aplikacje mogą odczytywać i zapisywać pliki oznaczone etykietą app_data_file . Istnieją inne typy aplikacji. Na przykład isolated_app jest używana dla usług aplikacji z isolatedProcess=true w ich manifeście. Zamiast powtarzać regułę dla obu typów, Android używa atrybutu o nazwie appdomain dla wszystkich typów, które obejmują aplikacje:

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app, appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app, appdomain;

allow appdomain app_data_file:file { read write };

Po napisaniu reguły określającej nazwę atrybutu, nazwa ta jest automatycznie rozszerzana na listę domen lub typów powiązanych z atrybutem. Niektóre godne uwagi atrybuty to:

• domain - atrybut powiązany ze wszystkimi typami procesów,
• file_type - atrybut powiązany ze wszystkimi typami plików.

Makra

W szczególności w przypadku dostępu do plików należy wziąć pod uwagę wiele rodzajów uprawnień. Na przykład uprawnienia do read nie wystarczają do otwarcia pliku lub wywołania na nim stat . Aby uprościć definicję reguły, system Android udostępnia zestaw makr do obsługi najczęstszych przypadków. Na przykład, aby uwzględnić brakujące uprawnienia, takie jak open , powyższa reguła może zostać przepisana jako:

allow appdomain app_data_file:file rw_file_perms;

Zobacz pliki global_macros i te_macros , aby uzyskać więcej przykładów przydatnych makr. W miarę możliwości należy używać makr, aby zmniejszyć prawdopodobieństwo niepowodzeń z powodu odmowy powiązanych uprawnień.

Po zdefiniowaniu typu należy go skojarzyć z plikiem lub procesem, który reprezentuje. Zobacz Implementing SELinux , aby uzyskać więcej informacji na temat tego, jak to powiązanie jest wykonywane. Więcej informacji na temat reguł znajdziesz w Notatniku SELinux .

Kontekst i kategorie bezpieczeństwa

Podczas debugowania polityk SELinux lub etykietowania plików (poprzez file_contexts lub podczas uruchamiania ls -Z ), możesz natknąć się na kontekst bezpieczeństwa (znany również jako etykieta ). Na przykład: u:r:untrusted_app:s0:c15,c256,c513,c768 . Kontekst bezpieczeństwa ma format: user:role:type:sensitivity[:categories] . Zazwyczaj można zignorować pola user , role i sensitivity kontekstu (patrz Specyfika ). Pole type zostało wyjaśnione w poprzedniej sekcji. categories są częścią obsługi Multi-Level Security (MLS) w SELinux. Od Androida S kategorie służą do:

• Odizoluj dane aplikacji od dostępu innej aplikacji,
• Izoluj dane aplikacji od jednego fizycznego użytkownika do drugiego.

Specyficzność

Android nie wykorzystuje wszystkich funkcji oferowanych przez SELinux. Czytając dokumentację zewnętrzną, pamiętaj o następujących punktach:

• Większość zasad w AOSP jest definiowana przy użyciu języka zasad jądra. Istnieją pewne wyjątki dotyczące używania wspólnego języka pośredniego (CIL).
• Użytkownicy SELinux nie są wykorzystywani. Jedynym zdefiniowanym użytkownikiem jest u . W razie potrzeby użytkownicy fizyczni są reprezentowani za pomocą pola kategorii kontekstu zabezpieczeń.
• Role SELinux i kontrola dostępu oparta na rolach (RBAC) nie są używane. Zdefiniowane i używane są dwie domyślne role: r dla podmiotów i object_r dla obiektów.
• Czułości SELinux nie są używane. Domyślna czułość s0 jest zawsze ustawiona.
• Wartości logiczne SELinux nie są używane. Po utworzeniu zasad dla urządzenia nie zależy to od stanu urządzenia. Upraszcza to inspekcję i debugowanie zasad.