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 z Linuksa uznaniowego systemu 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 zazwyczaj drobnoziarniste i podlega niezamierzonej eskalacji uprawnień. Jednakże system MAC konsultuje się z organem centralnym w celu podjęcia decyzji w sprawie wszystkich prób dostępu.
SELinux został zaimplementowany jako część frameworka Linux Security Module (LSM), który rozpoznaje różne obiekty jądra i wykonywane na nich wrażliwe akcje. W momencie, w którym każda z tych akcji zostanie wykonana, wywoływana jest funkcja przechwytująca LSM w celu ustalenia, czy dana akcja powinna być dozwolona, czy też nie, na podstawie informacji o niej przechowywanych w nieprzezroczystym obiekcie zabezpieczającym. SELinux zapewnia implementację tych zaczepów i zarządzanie tymi obiektami bezpieczeństwa, które w połączeniu z własną polityką pozwalają określić decyzje dotyczące dostępu.
Wraz z innymi środkami bezpieczeństwa Androida, zasady kontroli dostępu Androida znacznie ograniczają 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 przesłania danych przez błędne procesy.
W systemie Android 4.3 i nowszych wersjach SELinux zapewnia parasol obowiązkowej kontroli dostępu (MAC) w porównaniu z tradycyjnymi środowiskami uznaniowej kontroli dostępu (DAC). Na przykład oprogramowanie musi zazwyczaj działać na koncie użytkownika root, aby móc zapisywać dane na surowych urządzeniach blokowych. W tradycyjnym środowisku Linux opartym na przetworniku DAC, jeśli użytkownik root zostanie naruszony, może on pisać na każdym surowym urządzeniu blokowym. Jednakże SELinux może być używany do etykietowania tych urządzeń, tak aby proces z przypisanymi uprawnieniami roota mógł zapisywać tylko te określone w powiązanej polityce. W ten sposób proces nie może nadpisać danych i ustawień systemowych poza konkretnym surowym urządzeniem blokowym.
Więcej przykładów zagrożeń i sposobów radzenia sobie z nimi za pomocą SELinux można znaleźć w sekcji Przypadki użycia .
Poziomy egzekwowania
SELinux można wdrożyć w różnych trybach:
- Permissive — polityka bezpieczeństwa SELinux nie jest wymuszana, a jedynie rejestrowana.
- Egzekwowanie — zasady bezpieczeństwa są egzekwowane i rejestrowane. Awarie pojawiają się jako błędy EPERM.
Ten wybór ma charakter binarny i określa, czy Twoja polityka podejmie działanie, czy jedynie pozwoli Ci zebrać potencjalne niepowodzenia. Permisywny jest szczególnie przydatny podczas wdrażania.
Typy, atrybuty i reguły
Android w swoich zasadach opiera się na komponencie Type Enforcement (TE) systemu SELinux. Oznacza to, że wszystkie obiekty (takie jak plik, proces lub gniazdo) mają przypisany typ . Na przykład domyślnie aplikacja będzie miała typ untrusted_app . W przypadku procesu jego typ jest również nazywany jego domeną . Możliwe jest opisanie typu jednym lub wieloma atrybutami . Atrybuty są przydatne w przypadku odwoływania się do wielu typów jednocześnie.
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 pozwolenie na open file klasy. Chociaż typy i atrybuty są regularnie aktualizowane w ramach zasad Androida SELinux, uprawnienia i klasy są zdefiniowane statycznie i rzadko aktualizowane w ramach nowej wersji Linuksa.
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 żądany jest dostęp?
- Klasa – rodzaj obiektu (np. pliku, gniazda), do którego uzyskuje się dostęp.
- Uprawnienia — wykonywana operacja (lub zestaw operacji) (np. odczyt, zapis).
Przykładowa reguła to:
allow untrusted_app app_data_file:file { read write };
Oznacza to, że aplikacje mogą czytać i zapisywać pliki oznaczone etykietą app_data_file . Istnieją inne typy aplikacji. Na przykład isolated_app jest używana w przypadku usług aplikacji z isolatedProcess=true w manifeście. Zamiast powtarzać regułę dla obu typów, Android używa atrybutu o nazwie appdomain dla wszystkich typów obejmujących 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 };
Gdy zostanie napisana reguła określająca nazwę atrybutu, nazwa ta zostanie automatycznie rozszerzona na listę domen lub typów skojarzonych 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
Szczególnie w przypadku dostępu do plików należy wziąć pod uwagę wiele rodzajów uprawnień. Na przykład uprawnienie read nie wystarczy, aby otworzyć plik lub wywołać na nim stat . Aby uprościć definicję reguły, Android udostępnia zestaw makr obsługujących najczęstsze przypadki. Na przykład, aby uwzględnić brakujące uprawnienia, takie jak open , powyższą regułę można przepisać w następujący sposób:
allow appdomain app_data_file:file rw_file_perms;
Więcej przykładów przydatnych makr znajdziesz w plikach global_macros i te_macros . Makra powinny być używane, gdy tylko jest to możliwe, aby zmniejszyć prawdopodobieństwo awarii z powodu odmowy powiązanych uprawnień.
Po zdefiniowaniu typu należy go powiązać z plikiem lub procesem, który reprezentuje. Zobacz Implementowanie SELinux , aby uzyskać więcej szczegółów na temat wykonywania tego powiązania. Więcej informacji na temat reguł znajdziesz w Notatniku SELinux .
Kontekst i kategorie zabezpieczeń
Podczas debugowania polityk SELinux lub etykietowania plików (poprzez file_contexts lub polecenie 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 zabezpieczeń ma format: user:role:type:sensitivity[:categories] . Zwykle można zignorować pola user , role i sensitivity kontekstu (zobacz Specyfika ). Pole type zostało wyjaśnione w poprzedniej sekcji. categories są częścią obsługi zabezpieczeń wielopoziomowych (MLS) w SELinux. Od wersji Androida S kategorie służą do:
- Izoluj dane aplikacji od dostępu innej aplikacji,
- Izoluj dane aplikacji od jednego użytkownika fizycznego do innego.
Specyficzność
Android nie wykorzystuje wszystkich funkcji udostępnianych przez SELinux. Czytając dokumentację zewnętrzną, należy pamiętać o następujących kwestiach:
- Większość polityk w AOSP jest zdefiniowana 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 przy użyciu pola kategorii kontekstu zabezpieczeń. - Role SELinux i kontrola dostępu oparta na rolach (RBAC) nie są używane. Zdefiniowano i użyto dwóch domyślnych ról:
rdla podmiotów iobject_rdla obiektów. - Czułość SELinux nie jest używana. Domyślna czułość
s0jest 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.