Zgodność z zasadami

Na tej stronie opisujemy, jak Android radzi sobie z problemami ze zgodnością zasad podczas aktualizacji platformy OTA, gdy nowe ustawienia SELinux platformy mogą różnić się od starych ustawień SELinux dostawcy.

Własność obiektów i ich oznaczanie

Własność każdego obiektu musi być jasno określona, aby zachować rozdzielenie zasad platformy i zasad dostawcy. Jeśli na przykład zasady dostawcy oznaczają /dev/foo, a zasady platformy oznaczają /dev/foo w kolejnej aktualizacji OTA, wystąpi nieokreślone zachowanie, takie jak nieoczekiwane odrzucenie lub, co ważniejsze, błąd rozruchu. W przypadku SELinux objawia się to jako kolizja etykiet. Węzeł urządzenia może mieć tylko jedną etykietę, która jest ostatnią zastosowaną etykietą. W rezultacie:

  • Procesy, które potrzebują dostępu do etykiety, której nie udało się zastosować, tracą dostęp do zasobu.
  • Procesy, które uzyskują dostęp do pliku, mogą ulec awarii, ponieważ utworzono nieprawidłowy węzeł urządzenia.

Kolizje między etykietami platformy i dostawcy mogą wystąpić w przypadku dowolnego obiektu, który ma etykietę SELinux, w tym właściwości, usług, procesów, plików i gniazd. Aby uniknąć tych problemów, wyraźnie określ własność tych obiektów.

Przestrzeń nazw typu lub atrybutu

Oprócz kolizji etykiet mogą też wystąpić kolizje nazw typów i atrybutów SELinux. SELinux nie zezwala na wiele deklaracji tych samych typów i atrybutów. Zasady z powtarzającymi się deklaracjami nie zostaną skompilowane. Aby uniknąć kolizji nazw typów i atrybutów, zalecamy, aby wszystkie deklaracje dostawców zaczynały się od prefiksu vendor_. Na przykład sprzedawcy powinni używać znacznika type vendor_foo, domain; zamiast type foo, domain;.

Własność pliku

Zapobieganie kolizjom w przypadku plików jest trudne, ponieważ zasady platformy i dostawcy zwykle udostępniają etykiety dla wszystkich systemów plików. W przeciwieństwie do nazewnictwa typów, przestrzenie nazw plików nie są praktyczne, ponieważ wiele z nich jest tworzonych przez jądro. Aby zapobiec takim kolizjom, postępuj zgodnie z wskazówkami dotyczącymi nazewnictwa systemów plików podanymi w tej sekcji. W przypadku Androida 8.0 są to zalecenia bez egzekwowania technicznego. W przyszłości te rekomendacje będą egzekwowane przez pakiet testów dostawcy (VTS).

System (/system)

Tylko obraz systemu musi zawierać etykiety dla komponentów /system–file_contexts, service_contexts itp. Jeśli etykiety dla komponentów /system zostaną dodane w zasadach dostawcy, aktualizacja OTA obejmująca tylko platformę może być niemożliwa.

Dostawca (/vendor)

Zasady SELinux w AOSP już oznaczają części partycji vendor, z którymi platforma wchodzi w interakcję, co umożliwia pisanie reguł SELinux dla procesów platformy, aby mogły one komunikować się z częściami partycji vendor lub uzyskiwać do nich dostęp. Przykłady:

/vendor path Etykieta dostarczona przez platformę Procesy platformy w zależności od etykiety
/vendor(/.*)? vendor_file Wszyscy klienci HAL w ramach, ueventd itp.
/vendor/framework(/.*)? vendor_framework_file dex2oat, appdomain itp.
/vendor/app(/.*)? vendor_app_file dex2oat, installd, idmap itp.
/vendor/overlay(/.*) vendor_overlay_file system_server, zygote, idmap itp.

W związku z tym podczas etykietowania dodatkowych plików w neverallows partycji należy przestrzegać określonych reguł (egzekwowanych za pomocą neverallows):vendor

  • vendor_file musi być domyślną etykietą wszystkich plików w partycji vendor. Zasada platformy wymaga tego, aby uzyskać dostęp do implementacji HAL przekazywania.
  • Wszystkie nowe exec_types dodane w vendor partycji za pomocą zasad dostawcy muszą mieć atrybut vendor_file_type. Jest to egzekwowane za pomocą reguł neverallow.
  • Aby uniknąć konfliktów z przyszłymi aktualizacjami platformy lub struktury, nie oznaczaj plików innych niż exec_types w partycji vendor.
  • Wszystkie zależności biblioteki w przypadku interfejsów HAL w tym samym procesie zidentyfikowanych przez AOSP muszą być oznaczone jako same_process_hal_file..

Procfs (/proc)

Pliki w /proc można oznaczać tylko etykietą genfscon. W Androidzie 7.0 zarówno zasady platformy, jak i zasady dostawcy używały genfscon do oznaczania plików w procfs.

Zalecenie: tylko etykiety zasad platformy /proc. Jeśli procesy dostawcy wymagają dostępu do plików w /proc, które są obecnie oznaczone domyślną etykietą (proc), zasady dostawcy nie powinny ich wyraźnie oznaczać, ale zamiast tego powinny używać ogólnego typu proc do dodawania reguł dla domen dostawcy. Dzięki temu aktualizacje platformy mogą uwzględniać przyszłe interfejsy jądra udostępniane przez procfs i w razie potrzeby wyraźnie je oznaczać.

Debugfs (/sys/kernel/debug)

Debugfs może być oznaczona w file_contexts i genfscon. W Androidzie 7.0–10 zarówno etykieta platformy, jak i etykieta dostawcy.debugfs

W Androidzie 11 debugfs nie można uzyskać dostępu ani zamontować na urządzeniach produkcyjnych. Producenci urządzeń powinni usunąć debugfs.

Tracefs (/sys/kernel/debug/tracing)

Tracefs może być oznaczona w file_contexts i genfscon. W Androidzie 7.0 tylko etykiety platformytracefs.

Rekomendacja: tylko platforma może oznaczać tracefs.

Sysfs (/sys)

Pliki w /sys mogą być oznaczane etykietami za pomocą file_contexts i genfscon. W Androidzie 7.0 zarówno platforma, jak i dostawca używają genfscon do oznaczania plików w sysfs.

Rekomendacja: platforma może oznaczać sysfswęzły, które nie są specyficzne dla urządzenia. W przeciwnym razie tylko dostawca może oznaczać pliki.

tmpfs (/dev)

Pliki w folderze /dev mogą być oznaczone etykietami w usłudze file_contexts. W Androidzie 7.0 zarówno platforma, jak i dostawca mają tutaj pliki etykiet.

Zalecenie: dostawca może oznaczać tylko pliki w /dev/vendor (np. /dev/vendor/foo, /dev/vendor/socket/bar).

Rootfs (/)

Pliki w folderze / mogą być oznaczone etykietami w usłudze file_contexts. W Androidzie 7.0 znajdują się tu pliki etykiet platformy i dostawcy.

Zalecenie: tylko system może oznaczać pliki w /.

Dane (/data)

Dane są oznaczane etykietami za pomocą kombinacji file_contexts i seapp_contexts.

Rekomendacja: nie zezwalaj na etykietowanie przez dostawcę poza /data/vendor. Tylko platforma może oznaczać inne części/data.

Wersja etykiet Genfs

Począwszy od poziomu interfejsu API dostawcy 202504, nowsze etykiety SELinux przypisywane za pomocą genfscon w system/sepolicy/compat/plat_sepolicy_genfs_ver.cil są opcjonalne w przypadku starszych partycji vendor. Dzięki temu starsze partycjevendor mogą zachować dotychczasową implementację SEPolicy. Jest to kontrolowane przez zmienną pliku Makefile BOARD_GENFS_LABELS_VERSION, która jest przechowywana w /vendor/etc/selinux/genfs_labels_version.txt.

Przykład:

  • W interfejsie API dostawcy na poziomie 202404 węzeł /sys/class/udc jest domyślnie oznaczony etykietą sysfs.
  • Od poziomu interfejsu API dostawcy 202504 parametr /sys/class/udc jest oznaczony jako sysfs_udc.

/sys/class/udc może być jednak używane przez vendor partycje korzystające z interfejsu API na poziomie 202404, z domyślną etykietą sysfs lub etykietą dostawcy. Bezwarunkowe oznaczanie /sys/class/udc jako sysfs_udc może spowodować utratę zgodności z tymi partycjami vendor. Jeśli zaznaczysz pole wyboru BOARD_GENFS_LABELS_VERSION, platforma będzie nadal używać poprzednich etykiet i uprawnień w przypadku starszych partycji vendor.

BOARD_GENFS_LABELS_VERSION może być równa lub większa niż poziom interfejsu API dostawcy. Na przykład vendor partycje korzystające z interfejsu API na poziomie 202404 mogą ustawić BOARD_GENFS_LABELS_VERSION na 202504, aby zastosować nowe etykiety wprowadzone w 202504 r. Zobacz listę etykiet genfs dotyczących kodu 202504.

Podczas etykietowania węzłów genfscon platforma musi uwzględniać starsze partycje vendor i w razie potrzeby wdrażać mechanizmy rezerwowe zapewniające zgodność. Platforma może używać bibliotek dostępnych tylko na platformie do wysyłania zapytań o wersję etykiet genfs.

Polityka publiczna platformy

Polityka SELinux platformy jest podzielona na część prywatną i publiczną. Zasady publiczne platformy składają się z typów i atrybutów, które są zawsze dostępne na poziomie interfejsu API dostawcy, pełniąc funkcję interfejsu API między platformą a dostawcą. Ta zasada jest udostępniana autorom zasad dostawców, aby umożliwić im tworzenie plików zasad dostawców, które w połączeniu z zasadami prywatnymi platformy tworzą w pełni funkcjonalne zasady dotyczące urządzenia. Zasady platformy są zdefiniowane w system/sepolicy/public.

Na przykład typ vendor_init, reprezentujący proces inicjowania w kontekście dostawcy, jest zdefiniowany w system/sepolicy/public/vendor_init.te: 

type vendor_init, domain;

Dostawcy mogą użyć typu vendor_init, aby napisać niestandardowe reguły zasad: 

# Allow vendor_init to set vendor_audio_prop in vendor's init scripts
set_prop(vendor_init, vendor_audio_prop)

Atrybuty zgodności

Zasady SELinux to interakcja między typami źródłowymi i docelowymi w przypadku określonych klas obiektów i uprawnień. Każdy obiekt (np. procesy, pliki) objęty zasadami SELinux może mieć tylko 1 typ, ale ten typ może mieć wiele atrybutów.

Zasady są w większości sformułowane w odniesieniu do istniejących typów. W tym przypadku zarówno vendor_init, jak i debugfs są typami: 

allow vendor_init debugfs:dir { mounton };

Działa to dlatego, że zasady zostały opracowane z uwzględnieniem wszystkich typów. Jeśli jednak zasady dostawcy i zasady platformy używają określonych typów, a etykieta konkretnego obiektu zmieni się tylko w jednych z tych zasad, w drugich może znajdować się zasada, która wcześniej zyskała lub utraciła dostęp. Załóżmy na przykład, że etykiety zasad platformy oznaczają węzły sysfs jako sysfs: 

/sys(/.*)? u:object_r:sysfs:s0

Zasady dostawcy zapewniają dostęp do /sys/usb oznaczonego jakosysfs: 

allow vendor_init sysfs:chr_file rw_file_perms;

Jeśli zasady platformy zostaną zmienione tak, aby oznaczać /sys/usb jako sysfs_usb, zasady dostawcy pozostaną bez zmian, ale vendor_init utraci dostęp do /sys/usb z powodu braku zasad dotyczących nowego typu sysfs_usb: 

/sys/usb u:object_r:sysfs_usb:s0

Aby rozwiązać ten problem, Android wprowadza koncepcję atrybutów z określoną wersją. Podczas kompilacji system kompilacji automatycznie tłumaczy publiczne typy platformy używane w zasadach dostawcy na te atrybuty z określoną wersją. To tłumaczenie jest możliwe dzięki plikom mapowania, które łączą atrybut z wersją z co najmniej 1 publicznym typem z platformy.

Załóżmy na przykład, że w zasadach platformy 202504 element /sys/usb jest oznaczony etykietą sysfs, a zasady dostawcy 202504 przyznają elementowi vendor_init dostęp do elementu /sys/usb. W takim przypadku:

  • Zasady dostawcy tworzą regułę allow vendor_init sysfs:chr_file rw_file_perms;, ponieważ /sys/usb jest oznaczony jako sysfs w zasadach platformy 202504. Gdy system kompilacji kompiluje zasady dostawcy, automatycznie tłumaczy regułę na allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms;. Atrybuty vendor_init_202504 i sysfs_202504 odpowiadają typom vendor_init i sysfs, które są typami zdefiniowanymi przez platformę.
  • System kompilacji generuje plik mapowania tożsamości /system/etc/selinux/mapping/202504.cil. Ponieważ partycje system i vendor korzystają z tej samej wersji 202504, plik mapowania zawiera mapowania tożsamości z type_202504 na type. Na przykład:vendor_init_202504 jest mapowany na vendor_init, a sysfs_202504 jest mapowany na sysfs: 
    (typeattributeset sysfs_202504 (sysfs))
(typeattributeset vendor_init_202504 (vendor_init))
...

Gdy wersja zostanie zmieniona z 202504 na 202604, w folderze system/sepolicy/private/compat/202504/202504.cil zostanie utworzony nowy plik mapowania dla partycji 202504 vendor, który zostanie zainstalowany w folderze /system/etc/selinux/mapping/202504.cil na partycjach 202604 lub nowszych system. Początkowo ten plik mapowania zawiera mapowania tożsamości, jak opisano wcześniej. Jeśli do zasad platformy 202604 zostanie dodana nowa etykieta sysfs_usb dla /sys/usb, plik mapowania zostanie zaktualizowany, aby zmapować sysfs_202504 na sysfs_usb: 

(typeattributeset sysfs_202504 (sysfs sysfs_usb))
(typeattributeset vendor_init_202504 (vendor_init))
...

Ta aktualizacja umożliwia przekonwertowanej regule zasad dostawcy allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; automatyczne przyznawanie vendor_init dostępu do nowego typu sysfs_usb.

Aby zachować zgodność ze starszymi partycjami vendor, za każdym razem, gdy dodawany jest nowy typ publiczny, musi on być mapowany na co najmniej jeden z atrybutów z określoną wersją w pliku mapowania system/sepolicy/private/compat/ver/ver.cil lub musi być wymieniony w sekcji system/sepolicy/private/compat/ver/ver.ignore.cil, aby wskazać, że w poprzednich wersjach dostawcy nie ma pasującego typu.

Połączenie zasad platformy, zasad dostawcy i pliku mapowania umożliwia aktualizację systemu bez aktualizowania zasad dostawcy. Konwersja na atrybuty z określoną wersją odbywa się automatycznie, więc zasady sprzedawcy nie muszą uwzględniać wersji. Można nadal używać typów publicznych w niezmienionej postaci.

system_ext public and product public policy

Od Androida 11 partycje system_ext i product mogą eksportować wyznaczone typy publiczne do partycji vendor. Podobnie jak w przypadku zasad publicznych platformy, zasady dostawcy korzystają z typów i reguł automatycznie tłumaczonych na atrybuty z określoną wersją, np. z type na type_ver, gdzie ver to poziom interfejsu API dostawcy w przypadku partycji vendor.

Gdy partycje system_ext i product są oparte na tej samej wersji platformyver, system kompilacji generuje podstawowe pliki mapowania do system_ext/etc/selinux/mapping/ver.cil i product/etc/selinux/mapping/ver.cil, które zawierają mapowania tożsamości z type na type_ver. Zasady dostawcy mogą uzyskać dostęp do type za pomocą atrybutu z określoną wersją type_ver.

Jeśli zaktualizowane zostaną tylko partycje system_ext i product, np. z ver na ver+1 (lub nowszą), a partycja vendor pozostanie na poziomie ver, zasady dostawcy mogą utracić dostęp do typów partycji system_ext i product. Aby zapobiec przerwaniu, partycje system_ext i product powinny udostępniać pliki mapowania z konkretnych typów na atrybuty type_ver. Każdy partner jest odpowiedzialny za utrzymywanie plików mapowania, jeśli obsługuje partycję ver vendor z ver+1 (lub nowszą) system_ext i partycje product.

Aby zainstalować pliki mapowania na partycjach system_ext i product, producenci urządzeń lub dostawcy powinni:

  1. Skopiuj wygenerowane podstawowe pliki mapowania z partycji ver, system_ext i product do drzewa źródłowego.
  2. W razie potrzeby zmień pliki mapowania.
  3. Zainstaluj pliki mapowania na partycjach ver+1 (lub nowszych) system_ext i product.

Załóżmy na przykład, że partycja 202504 system_ext ma jeden typ publiczny o nazwie foo_type. W takim przypadku partycja 202504 system_ext wygląda tak:system_ext/etc/selinux/mapping/202504.cil 

(typeattributeset foo_type_202504 (foo_type))
(expandtypeattribute foo_type_202504 true)
(typeattribute foo_type_202504)

Jeśli do 202604 system_ext zostanie dodany element bar_type, a element bar_type powinien być mapowany na foo_type w przypadku partycji 202504 vendor, element 202504.cil można zaktualizować z (typeattributeset foo_type_202504 (foo_type)) na (typeattributeset foo_type_202504 (foo_type bar_type)), a następnie zainstalować w partycji 202604 system_ext. Partycja 202504 vendor może nadal uzyskiwać dostęp do foo_type i bar_type partycji 202604 system_ext.

Zmiany atrybutów w Androidzie 9

Urządzenia, które zostaną zaktualizowane do Androida 9, mogą używać tych atrybutów, ale urządzenia z Androidem 9 nie mogą.

Atrybuty naruszającego

Android 9 zawiera te atrybuty związane z domeną:

  • data_between_core_and_vendor_violators. Atrybut wszystkich domen, które naruszają wymaganie dotyczące nieudostępniania plików według ścieżki między vendor a coredomains. Procesy platformy i dostawcy nie powinny używać plików na dysku do komunikacji (niestabilny interfejs ABI). Rekomendacja:
    • Kod dostawcy powinien używać /data/vendor.
    • System nie powinien używać /data/vendor.
  • system_executes_vendor_violators. Atrybut dla wszystkich domen systemowych (z wyjątkiem init i shell domains) naruszających wymaganie dotyczące niewykonywania plików binarnych dostawcy. Wykonywanie binarnych plików dostawcy ma niestabilny interfejs API. Platforma nie powinna bezpośrednio wykonywać plików binarnych dostawcy. Rekomendacja:
    • Takie zależności platformy od plików binarnych dostawcy muszą być ukryte za interfejsami HIDL HAL.

      LUB

    • coredomains, które potrzebują dostępu do plików binarnych dostawcy, powinny zostać przeniesione do partycji vendor i tym samym przestać być coredomain.

Niezaufane atrybuty

Niezaufane aplikacje, które hostują dowolny kod, nie powinny mieć dostępu do usług HwBinder, z wyjątkiem tych, które są uważane za wystarczająco bezpieczne, aby można było z nich korzystać w takich aplikacjach (patrz bezpieczne usługi poniżej). Główne powody to:

  1. Serwery HwBinder nie przeprowadzają uwierzytelniania klienta, ponieważ HIDL nie udostępnia obecnie informacji o identyfikatorze UID wywołującego. Nawet jeśli HIDL udostępniałby takie dane, wiele usług HwBinder działa na poziomie niższym niż aplikacje (np. HAL) lub nie może polegać na tożsamości aplikacji w celu autoryzacji. Dlatego dla bezpieczeństwa domyślnym założeniem jest to, że każda usługa HwBinder traktuje wszystkich klientów jako równie uprawnionych do wykonywania operacji oferowanych przez usługę.
  2. Serwery HAL (podzbiór usług HwBinder) zawierają kod, w którym występuje więcej problemów z bezpieczeństwem niż w system/core. Mają też dostęp do niższych warstw stosu (aż do sprzętu), co zwiększa możliwości obejścia modelu zabezpieczeń Androida.

Usługi związane z sejfami

Bezpieczne usługi obejmują:

  • same_process_hwservice. Te usługi (z definicji) działają w procesie klienta, a tym samym mają taki sam dostęp jak domena klienta, w której działa proces.
  • coredomain_hwservice. Te usługi nie stwarzają zagrożeń związanych z przyczyną nr 2.
  • hal_configstore_ISurfaceFlingerConfigs. Ta usługa jest przeznaczona do użytku w dowolnej domenie.
  • hal_graphics_allocator_hwservice. Te operacje są też dostępne w usłudze surfaceflinger Binder, do której aplikacje mają dostęp.
  • hal_omx_hwservice. Jest to wersja usługi Binder w HwBinder, do której aplikacje mają dostęp.mediacodec
  • hal_codec2_hwservice. To nowsza wersja usługi hal_omx_hwservice.

Atrybuty, których można używać

Wszystkie hwservices, które nie są uważane za bezpieczne, mają atrybut untrusted_app_visible_hwservice. Odpowiednie serwery HAL mają atrybut untrusted_app_visible_halserver. Urządzenia z Androidem 9 NIE MOGĄ używać atrybutu untrusted.

Rekomendacja:

  • Niezaufane aplikacje powinny komunikować się z usługą systemową, która komunikuje się z interfejsem HAL HIDL dostawcy. Na przykład aplikacje mogą komunikować się z binderservicedomain, a potem z mediaserver (czyli binderservicedomain), które z kolei komunikuje się z hal_graphics_allocator.

    LUB

  • Aplikacje, które potrzebują bezpośredniego dostępu do vendor HAL, powinny mieć własną domenę sepolicy zdefiniowaną przez dostawcę.

Testy atrybutów plików

Android 9 zawiera testy czasu kompilacji, które sprawdzają, czy wszystkie pliki w określonych lokalizacjach mają odpowiednie atrybuty (np. czy wszystkie pliki w sysfs mają wymagany atrybut sysfs_type).

Oznaczanie kontekstów SELinux

Aby rozróżnić zasady SELinux platformy i dostawcy, system tworzy pliki kontekstu SELinux w inny sposób, aby je rozdzielić.

Konteksty plików

W Androidzie 8.0 wprowadzono te zmiany dotyczące file_contexts:

  • Aby uniknąć dodatkowych obciążeń związanych z kompilacją na urządzeniu podczas uruchamiania, file_contexts nie będą już istniały w formie binarnej. Zamiast tego są to czytelne pliki tekstowe z wyrażeniami regularnymi, np. {property, service}_contexts (tak jak w wersjach wcześniejszych niż 7.0).
  • file_contexts są podzielone na 2 pliki:
    • plat_file_contexts
      • Platforma Androidfile_context, która nie ma etykiet specyficznych dla urządzenia, z wyjątkiem etykietowania części partycji /vendor, które musi być precyzyjne, aby zapewnić prawidłowe działanie plików sepolicy.
      • Musi znajdować się w partycji system na urządzeniu /system/etc/selinux/plat_file_contexts i być wczytywana przez init na początku wraz z file_context dostawcy.
    • vendor_file_contexts
      • Specyficzne dla urządzenia file_context utworzone przez połączenie file_contexts znalezionych w katalogach wskazanych przez BOARD_SEPOLICY_DIRS w plikach Boardconfig.mk urządzenia.
      • Musi być zainstalowany w /vendor/etc/selinux/vendor_file_contexts na partycji vendor i ładowany przez init na początku wraz z platformą file_context.

Konteksty usługi

W Androidzie 8.0 property_contexts jest podzielony na 2 pliki:

  • plat_property_contexts
    • platformy Androidproperty_context, która nie ma etykiet przypisanych do konkretnych urządzeń.
    • Musi znajdować się w partycji system w /system/etc/selinux/plat_property_contexts i być wczytywana przez init na początku wraz z property_contexts.
  • vendor_property_contexts
    • Specyficzne dla urządzenia property_context, które powstają przez połączenie property_contexts znalezionych w katalogach wskazywanych przez BOARD_SEPOLICY_DIRS w plikach Boardconfig.mk urządzenia.
    • Musi znajdować się w partycji vendor w /vendor/etc/selinux/vendor_property_contexts i być wczytywana przez init na początku wraz z platformą property_context.

Konteksty usług

W Androidzie 8.0 service_contexts jest podzielony na te pliki:

  • plat_service_contexts
    • service_context dla platformy Androidservicemanager. service_context nie ma etykiet przypisanych do konkretnych urządzeń.
    • Musi znajdować się w system partycji w /system/etc/selinux/plat_service_contexts i być wczytywana przez servicemanager na początku wraz z service_contexts.
  • vendor_service_contexts
    • service_context – tworzone przez połączenie service_contexts – znajdujące się w katalogach wskazywanych przez BOARD_SEPOLICY_DIRS – w plikach Boardconfig.mk – urządzenia.
    • Musi znajdować się w partycji vendor w /vendor/etc/selinux/vendor_service_contexts i być wczytywana przez servicemanager na początku wraz z platformą service_contexts.
    • Chociaż servicemanager szuka tego pliku podczas uruchamiania, w przypadku w pełni zgodnego urządzenia TREBLE plik vendor_service_contexts NIE MOŻE istnieć. Dzieje się tak, ponieważ wszystkie interakcje między procesami vendor i system MUSZĄ przechodzić przez hwservicemanager/hwbinder.
  • plat_hwservice_contexts
    • platformy Androidhwservice_context, którahwservicemanager nie ma etykiet specyficznych dla urządzenia.
    • Musi znajdować się w partycji system w lokalizacji /system/etc/selinux/plat_hwservice_contexts i być wczytywany przez hwservicemanager na początku razem z vendor_hwservice_contexts.
  • vendor_hwservice_contexts
    • hwservice_context – tworzone przez połączenie hwservice_contexts – znajdujące się w katalogach wskazywanych przez BOARD_SEPOLICY_DIRS – w plikach Boardconfig.mk – urządzenia.
    • Musi znajdować się w partycji vendor pod adresem /vendor/etc/selinux/vendor_hwservice_contexts i być wczytywany przez hwservicemanager na początku wraz z plat_service_contexts.
  • vndservice_contexts
    • service_context specyficzne dla urządzenia, które są vndservicemanager tworzone przez połączenie vndservice_contexts znalezionych w katalogach wskazywanych przez BOARD_SEPOLICY_DIRS w Boardconfig.mk urządzenia.
    • Ten plik musi znajdować się w partycji vendor w lokalizacji /vendor/etc/selinux/vndservice_contexts i być wczytywany przez vndservicemanager na początku.

Konteksty Seapp

W Androidzie 8.0 seapp_contexts jest podzielony na 2 pliki:

  • plat_seapp_contexts
    • platformy Androidseapp_context, która nie ma zmian specyficznych dla urządzenia.
    • Musi znajdować się w partycji system w /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Rozszerzenie platformy seapp_context specyficzne dla urządzenia, utworzone przez połączenie seapp_contexts znalezionych w katalogach, na które wskazują BOARD_SEPOLICY_DIRS w plikach Boardconfig.mk urządzenia.
    • Musi znajdować się w partycji vendor w /vendor/etc/selinux/vendor_seapp_contexts.

Uprawnienia MAC

W Androidzie 8.0 mac_permissions.xml jest podzielony na 2 pliki:

  • Platforma mac_permissions.xml
    • platformy Androidmac_permissions.xml, która nie ma zmian specyficznych dla urządzenia.
    • Musi znajdować się w partycji system w /system/etc/selinux/.
  • Non-Platform mac_permissions.xml
    • Rozszerzenie platformy specyficzne dla urządzenia mac_permissions.xml utworzone na podstawie mac_permissions.xml znalezionych w katalogach wskazywanych przez BOARD_SEPOLICY_DIRS w plikach Boardconfig.mk urządzenia.
    • Musi znajdować się w partycji vendor w /vendor/etc/selinux/.