Pojęcia związane z SELinux

Przejrzyj tę stronę, aby zapoznać się z pojęciami dotyczącymi 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ę on od systemu Linux do znanych systemów dyskretnej kontroli dostępu (DAC). W systemie DAC koncepcja prawa własności, gdzie właściciel określonego zasobu kontroluje dostęp i uprawnieniach z nim powiązanych. Jest to zwykle problem o dużej ziarnistości do niezamierzonej eskalacji uprawnień. System MAC konsultuje się jednak z decyzji o wszystkich próbach dostępu.

SELinux został wdrożony jako część modułu zabezpieczeń systemu Linux (LSM). która rozpoznaje różne obiekty jądra oraz działania newralgiczne na nich. W momencie, w którym każde z tych działań byłoby funkcji hook LSM, aby sprawdzić, czy działanie powinno być dozwolone na podstawie informacji o nim przechowywanych w nieprzezroczystym miejscu obiekt zabezpieczeń. SELinux zapewnia implementację dla tych punktów zaczepienia. zarządzania tymi obiektami zabezpieczeń, w połączeniu z własnymi zasadami, i w ten sposób podejmować decyzje dotyczące dostępu.

Oprócz innych zabezpieczeń Androida kontrola dostępu zasadniczo ogranicza potencjalne szkody powstałe w wyniku przejęcia komputera kont. Korzystanie z narzędzi takich jak wybór systemu Android i obowiązkowy dostęp elementy sterujące zapewniają strukturę pozwalającą na zapewnienie, że oprogramowanie działa tylko na minimalnym poziomie poziom uprawnień. Minimalizuje to skutki ataków i zmniejsza ryzyko prawdopodobieństwo zastąpienia lub nawet transmisji danych przez błędne procesy.

W Androidzie 4.3 i nowszych SELinux zapewnia obowiązkową kontrolę dostępu (MAC). nad tradycyjnymi środowiskami dyskrecjonalnej kontroli dostępu (DAC). Dla: na przykład oprogramowanie musi zwykle działać jako konto roota w celu zapisu w blokować urządzenia. W tradycyjnym środowisku Linux opartym na przenikach DAC, jeśli użytkownik root zostanie przejęte, aby użytkownik mógł zapisywać dane na każdym nieprzetworzonym urządzeniu blokowym. Pamiętaj jednak: SELinux może być używany do oznaczania tych urządzeń etykietami, aby procesowi przypisał katalog główny. mogą zapisywać tylko te uprawnienia określone w powiązanej zasadzie. W tym proces nie może zastępować danych ani ustawień systemu poza konkretne urządzenie z nieprzetworzonym blokiem.

Zobacz przypadki użycia .

Poziomy egzekwowania zasad

SELinux można wdrożyć w różnych trybach:

  • Tryb mniej rygorystyczny – zasada zabezpieczeń SELinux nie jest egzekwowana. Zasada jest logowana.
  • Wymuszanie – zasada zabezpieczeń jest egzekwowana i rejestrowana. Błędy będą wyświetlane jako błędy EPERM.

Ten wybór ma charakter binarny i określa, czy zasady zostaną zastosowane, czy tylko pozwala na gromadzenie potencjalnych błędów. Tryb mniej rygorystyczny jest szczególnie przydatny implementacji.

Typy, atrybuty i reguły

Android korzysta z komponentu egzekwowania zasad (TE) systemu SELinux. . Oznacza to, że wszystkie obiekty (takie jak plik, proces lub gniazdo) mają type. Na przykład: domyślnie aplikacja będzie mieć typ untrusted_app. W przypadku procesu jego typ jest również jej domeny. Można dodać adnotację do typu za pomocą wiele atrybutów. Atrybuty przydają się do odwoływania się do wielu typów z powrotem.

Obiekty są mapowane na klasy. (np. plik, katalog, łącze symboliczne, gniazdo) oraz różne rodzaje dostępu dla poszczególnych zajęć są reprezentowane przez uprawnienia. Na przykład uprawnienie open istnieje dla klasy file Typy i atrybuty są regularnie aktualizowane w ramach zasady, uprawnienia i klasy systemu Android SELinux są statycznie zdefiniowane. rzadko aktualizowane jako część nowej wersji systemu Linux.

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

  • Źródło – typ (lub atrybut) tematu reguły. Kto prosi o dostęp?
  • Element docelowy – typ (lub atrybut) obiektu. Do czego jest wymagana prośba o dostęp?
  • Klasa – rodzaj obiektu (np. plik, gniazdo), do którego uzyskiwany jest dostęp.
  • Uprawnienia – wykonywana operacja (lub zestaw operacji) (np. odczyt, zapis).

Oto przykład reguły:

allow untrusted_app app_data_file:file { read write };

Oznacza to, że aplikacje mogą odczytywać i zapisywać pliki z etykietą app_data_file Istnieją też inne typy aplikacji. Dla: instancji, isolated_app jest używany w przypadku usług aplikacji z atrybutem isolatedProcess=true w pliku manifestu. Zamiast powtarzać dla obu typów, Android używa atrybutu o nazwie appdomain w przypadku wszystkich typów aplikacji, 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 };

Jeśli zostanie napisana reguła określająca nazwę atrybutu, ta nazwa automatycznie rozwija się do listy domen lub typów powiązanych z . Oto niektóre ważne atrybuty:

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

Makra

Istnieje wiele rodzajów uprawnień dostępu do plików, do rozważenia. Na przykład uprawnienie read nie wystarcza do otwarcia lub wywołaj na nim stat. Aby uprościć definicję reguły, Android udostępnia zestaw makr do obsługi najczęstszych przypadków. Na przykład w kolejności, , aby uwzględnić brakujące uprawnienia, takie jak open, powyższa reguła można zapisać tak:

allow appdomain app_data_file:file rw_file_perms;

Zobacz global_macros i te_macros zawierające więcej przykładów przydatnych makr. Makra należy używać zawsze, gdy jest to możliwe aby zmniejszyć prawdopodobieństwo awarii spowodowanych odmowami dotyczącymi powiązanych uprawnień.

Zdefiniowany typ musi być powiązany z plikiem lub procesem. co reprezentuje. Patrz: Wdrażanie SELinux . Więcej informacji: zapoznaj się z Notatnik SELinux

Kontekst i kategorie zabezpieczeń

Podczas debugowania zasad SELinux lub oznaczania plików etykietami (za pomocą file_contexts lub dzwoniąc na: ls -Z), możesz odwiedzić w kontekście zabezpieczeń (nazywanym też etykietą). Dla: przykład: u:r:untrusted_app:s0:c15,c256,c513,c768 Kontekst zabezpieczeń ma format: user:role:type:sensitivity[:categories] Zwykle można zignorować user, role i sensitivity pola kontekstu (patrz Szczegółowość). type omówiono w poprzedniej sekcji. categories należą do: zabezpieczenia wielopoziomowe (MLS) z funkcjami SELinux. Android S umożliwia:

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

Specyficzność

Android nie wykorzystuje wszystkich funkcji udostępnianych przez SELinux. Podczas czytania dokumentację zewnętrzną, pamiętaj o tych kwestiach:

  • Większość zasad AOSP jest określana w języku zasad jądra. Istnieją pewne wyjątki dotyczące korzystania z wspólnego języka CIL (Common Intermediate Language).
  • Użytkownicy SELinux nie są dodawani. Jedynym zdefiniowanym przez użytkownika jest u W razie potrzeby użytkownicy fizyczni są reprezentowani za pomocą pola kategorii w kontekście zabezpieczeń.
  • Role SELinux i kontrola dostępu oparta na rolach (RBAC) nie są używane. Zdefiniowano i są używane 2 role domyślne: r dla obiektów i object_r dla obiektów.
  • Poufność SELinux nie są używane. Domyślnie czułość s0 jest zawsze ustawiona.
  • Wartości logiczne SELinux nie są używane. Po utworzeniu zasady dla urządzenia nie zależy od stanu urządzenia. Upraszcza to kontroli i debugowania zasad.