Совместимость политики

На этой странице описывается, как Android обрабатывает проблемы совместимости политик с беспроводными обновлениями платформы (OTA), при которых новые настройки SELinux платформы могут отличаться от старых настроек SELinux поставщика.

Право собственности на объект и маркировка

Владелец должен быть чётко определён для каждого объекта, чтобы политики платформы и поставщика были разделены. Например, если политика поставщика назначает метку /dev/foo , а политика платформы – метку /dev/foo в последующем OTA, возникнет неопределённое поведение, например, неожиданный отказ или, что ещё более важно, сбой загрузки. В SELinux это проявляется как конфликт меток. Узел устройства может иметь только одну метку, которая преобразуется в ту, которая была применена последней. В результате:

  • Процессы, которым необходим доступ к неудачно примененной метке, теряют доступ к ресурсу.
  • Процессы, получающие доступ к файлу, могут прерваться из-за создания неправильного узла устройства.

Конфликты между метками платформы и поставщика могут возникнуть для любого объекта с меткой SELinux, включая свойства, службы, процессы, файлы и сокеты. Чтобы избежать этих проблем, чётко определите владельца этих объектов.

Пространство имен типов/атрибутов

Помимо конфликтов меток, конфликтуют также имена типов и атрибутов SELinux. SELinux не допускает множественных объявлений одних и тех же типов и атрибутов. Политика с дублирующимися объявлениями не компилируется. Во избежание конфликтов имён типов и атрибутов настоятельно рекомендуется начинать все объявления вендоров с префикса vendor_ . Например, вендоры должны использовать type vendor_foo, domain; вместо type foo, domain;

Право собственности на файл

Предотвращение коллизий файлов представляет собой сложную задачу, поскольку политики платформы и поставщика обычно предусматривают метки для всех файловых систем. В отличие от именования типов, использование пространств имён файлов нецелесообразно, поскольку многие из них создаются ядром. Чтобы предотвратить эти коллизии, следуйте рекомендациям по именованию файловых систем, представленным в этом разделе. Для Android 8.0 эти рекомендации не имеют технического контроля. В будущем эти рекомендации будут контролироваться Vendor Test Suite (VTS).

Система (/система)

Только образ системы должен предоставлять метки для компонентов /system через file_contexts , service_contexts и т. д. Если метки для компонентов /system добавлены в политику поставщика, обновление OTA только для фреймворка может оказаться невозможным.

Поставщик (/vendor)

Политика SELinux AOSP уже маркирует части раздела vendor , с которыми взаимодействует платформа, что позволяет создавать правила SELinux для процессов платформы, чтобы они могли взаимодействовать с частями раздела vendor или получать к ним доступ. Примеры:

/путь поставщика Метка, предоставленная платформой Процессы платформы в зависимости от лейбла
/vendor(/. * )? vendor_file Все клиенты HAL в фреймворке, ueventd и т. д.
/vendor/framework(/. * )? vendor_framework_file dex2oat , appdomain и т. д.
/vendor/app(/. * )? vendor_app_file dex2oat , installd , idmap и т. д.
/vendor/overlay(/. * ) vendor_overlay_file system_server , zygote , idmap и т. д.

В результате при маркировке дополнительных файлов в разделе vendor необходимо соблюдать определенные правила (применяемые через neverallows ):

  • vendor_file должна быть меткой по умолчанию для всех файлов в разделе vendor . Политика платформы требует этого для доступа к реализациям HAL, проходящим через сервер.
  • Все новые exec_types добавляемые в раздел vendor через политику Vendor, должны иметь атрибут vendor_file_type . Это обеспечивается с помощью neverallows.
  • Чтобы избежать конфликтов с будущими обновлениями платформы/фреймворка, не маркируйте файлы, отличные от exec_types в разделе vendor .
  • Все зависимости библиотек для тех же процессов HAL, которые идентифицированы AOSP, должны быть помечены как same_process_hal_file.

Procfs (/proc)

Файлы в каталоге /proc можно пометить только меткой genfscon . В Android 7.0 как платформа , так и политика поставщика использовали genfscon для маркировки файлов в procfs .

Рекомендация: Только политика платформы помечает /proc . Если процессам поставщика требуется доступ к файлам в /proc , которые в настоящее время помечены меткой по умолчанию ( proc ), политика поставщика не должна явно помечать их, а вместо этого должна использовать общий тип proc для добавления правил для доменов поставщика. Это позволяет обновлениям платформы учитывать будущие интерфейсы ядра, предоставляемые через procfs , и явно помечать их по мере необходимости.

Debugfs (/sys/kernel/debug)

Debugfs могут быть помечены как в file_contexts , так и в genfscon . В версиях от Android 7.0 до Android 10 и платформа, и поставщик помечают debugfs .

В Android 11 debugfs недоступен и не монтируется на рабочих устройствах. Производителям устройств следует удалить debugfs .

Tracefs (/sys/kernel/debug/tracing)

Tracefs можно помечать как в file_contexts , так и genfscon . В Android 7.0 tracefs помечает только платформа.

Рекомендация: Только платформа может маркировать tracefs .

Sysfs (/sys)

Файлы в каталоге /sys могут быть помечены как с помощью file_contexts , так и с помощью genfscon . В Android 7.0 и платформа, и поставщик используют genfscon для маркировки файлов в sysfs .

Рекомендация: Платформа может маркировать узлы sysfs , не привязанные к конкретному устройству. В противном случае маркировать файлы может только поставщик.

tmpfs (/dev)

Файлы в каталоге /dev могут быть помечены в file_contexts . В Android 7.0 и платформа, и поставщик помечают файлы здесь.

Рекомендация: Поставщик может маркировать только файлы в /dev/vendor (например, /dev/vendor/foo , /dev/vendor/socket/bar ).

Rootfs (/)

Файлы в каталоге / могут быть помечены в file_contexts . В Android 7.0 и платформа, и поставщик помечают файлы здесь.

Рекомендация: Только система может маркировать файлы в / .

Данные (/данные)

Данные маркируются с помощью комбинации file_contexts и seapp_contexts .

Рекомендация: запретить маркировку поставщиков за пределами /data/vendor . Только платформа может маркировать другие части /data .

Версия меток Genfs

Начиная с уровня API вендора 202504, новые метки SELinux, назначенные с помощью genfscon в system/sepolicy/compat/plat_sepolicy_genfs_ ver .cil являются необязательными для разделов старых vendor . Это позволяет в разделах старых vendor сохранять существующую реализацию SEPolicy. Это управляется переменной Makefile BOARD_GENFS_LABELS_VERSION , которая хранится в /vendor/etc/selinux/genfs_labels_version.txt .

Пример:

  • На уровне API поставщика 202404 узел /sys/class/udc по умолчанию обозначен как sysfs .
  • Начиная с уровня API поставщика 202504, /sys/class/udc обозначается как sysfs_udc .

Однако /sys/class/udc может использоваться разделами vendor , использующими API уровня 202404, как с меткой sysfs по умолчанию, так и с меткой, специфичной для поставщика. Безоговорочная маркировка /sys/class/udc как sysfs_udc может нарушить совместимость с этими разделами vendor . Проверяя BOARD_GENFS_LABELS_VERSION , платформа продолжает использовать предыдущие метки и разрешения для старых разделов vendor .

BOARD_GENFS_LABELS_VERSION может быть больше или равно уровню API поставщика. Например, разделы vendor , использующие уровень API 202404, могут установить значение BOARD_GENFS_LABELS_VERSION равным 202504, чтобы использовать новые метки, представленные в версии 202504. См. список меток genfs, специфичных для версии 202504 .

При маркировке узлов genfscon платформа должна учитывать разделы старых vendor и при необходимости реализовывать резервные механизмы для обеспечения совместимости. Платформа может использовать библиотеки, доступные только платформе, для запроса версии меток genfs.

Платформа-государственная политика

Политика SELinux платформы делится на частную и публичную. Политика платформы-публичности состоит из типов и атрибутов, всегда доступных для уровня API поставщика , выступая в качестве API между платформой и поставщиком. Эта политика предоставляется разработчикам политик поставщиков, позволяя им создавать файлы политик поставщиков, которые в сочетании с частной политикой платформы создают полнофункциональную политику для устройства. Политика платформы-публичности определена в system/sepolicy/public .

Например, тип vendor_init , представляющий процесс init в контексте vendor, определен в system/sepolicy/public/vendor_init.te :

type vendor_init, domain;

Поставщики могут ссылаться на тип vendor_init для написания пользовательских правил политики:

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

Атрибуты совместимости

Политика SELinux — это взаимодействие между исходными и целевыми типами для определённых классов объектов и разрешений. Каждый объект (например, процессы, файлы), на который распространяется политика SELinux, может иметь только один тип, но этот тип может иметь несколько атрибутов.

Политика написана преимущественно на основе существующих типов. Здесь и vendor_init , и debugfs являются типами:

allow vendor_init debugfs:dir { mounton };

Это работает, поскольку политика была написана с учётом всех типов. Однако, если политика поставщика и политика платформы используют определённые типы, и метка конкретного объекта изменяется только в одной из этих политик, другая может содержать политику, которая даёт или лишает ранее полагавшийся доступ. Например, предположим, что политика платформы помечает узлы sysfs как sysfs :

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

Политика поставщика предоставляет доступ к /sys/usb , помеченному как sysfs :

allow vendor_init sysfs:chr_file rw_file_perms;

Если политика платформы изменена так, чтобы обозначить /sys/usb как sysfs_usb , политика поставщика останется прежней, но vendor_init потеряет доступ к /sys/usb из-за отсутствия политики для нового типа sysfs_usb :

/sys/usb u:object_r:sysfs_usb:s0

Для решения этой проблемы в Android реализована концепция версионированных атрибутов. Во время компиляции система сборки автоматически транслирует открытые типы платформы, используемые в политике поставщика, в эти версионированные атрибуты. Это преобразование осуществляется путём сопоставления файлов, которые связывают версионированный атрибут с одним или несколькими открытыми типами платформы.

Например, предположим, что /sys/usb помечен как sysfs в политике платформы 202504, а политика поставщика 202504 предоставляет vendor_init доступ к /sys/usb . В этом случае:

  • Политика поставщика записывает правило allow vendor_init sysfs:chr_file rw_file_perms; , поскольку /sys/usb помечен как sysfs в политике платформы 202504. Когда система сборки компилирует политику поставщика, она автоматически транслирует это правило в allow vendor_init _202504 sysfs _202504 :chr_file rw_file_perms; . Атрибуты vendor_init_202504 и sysfs_202504 соответствуют типам vendor_init и sysfs , которые определены платформой.
  • Система сборки генерирует файл сопоставления идентификаторов /system/etc/selinux/mapping/202504.cil . Поскольку и system , и разделы vendor используют одну и ту же версию 202504 , файл сопоставления содержит сопоставления идентификаторов из type_202504 в type . Например, vendor_init_202504 сопоставлено с vendor_init , а sysfs_202504 — с sysfs : 
    (typeattributeset sysfs_202504 (sysfs))
(typeattributeset vendor_init_202504 (vendor_init))
...

При повышении версии с 202504 до 202604 в каталоге system/sepolicy/private/compat/202504/202504.cil создаётся новый файл сопоставления для разделов vendor 202504, который устанавливается в /system/etc/selinux/mapping/202504.cil для разделов system 202604 и более новых. Изначально этот файл сопоставления содержит сопоставления идентификаторов, как описано ранее. Если в политику платформы 202604 добавляется новая метка sysfs_usb для /sys/usb , файл сопоставления обновляется для сопоставления sysfs_202504 с sysfs_usb :

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

Это обновление позволяет преобразованному правилу политики поставщика allow vendor_init_202504 sysfs_202504:chr_file rw_file_perms; автоматически предоставлять доступ vendor_init к новому типу sysfs_usb .

Для поддержания совместимости со старыми разделами vendor при каждом добавлении нового публичного типа этот тип должен быть сопоставлен по крайней мере с одним из версионных атрибутов в файле сопоставления system/sepolicy/private/compat/ ver / ver .cil или указан в system/sepolicy/private/compat/ ver / ver .ignore.cil чтобы указать, что в предыдущих версиях поставщика нет соответствующего типа.

Сочетание политики платформы, политики поставщика и файла сопоставления позволяет обновлять систему без обновления политики поставщика. Кроме того, преобразование в версионированные атрибуты происходит автоматически, поэтому политике поставщика не нужно заботиться о версионировании, и открытые типы данных используются как есть.

публичная и публичная политика продукта system_ext

Начиная с Android 11, разделы system_ext и product могут экспортировать свои назначенные публичные типы в раздел vendor . Как и публичная политика платформы, политика vendor использует типы и правила, автоматически транслируемые в версионные атрибуты, например, из type в type_ ver , где ver — уровень API вендора для раздела vendor .

Если разделы system_ext и product основаны на одной и той же версии платформы ver , система сборки генерирует базовые файлы сопоставления в system_ext/etc/selinux/mapping/ ver .cil и product/etc/selinux/mapping/ ver .cil , которые содержат сопоставления идентификаторов из type в type_ ver . Политика поставщика может получить доступ к type с помощью версионного атрибута type_ ver .

Если обновляются только разделы system_ext и product , например, до ver ver+1 (или более поздней версии), а раздел vendor остаётся на ver , политика vendor может потерять доступ к типам разделов system_ext и product . Во избежание сбоев разделы system_ext и product должны предоставлять файлы сопоставления конкретных типов с атрибутами type_ ver . Каждый партнёр несёт ответственность за поддержку файлов сопоставления, если он поддерживает разделы ver vendor с system_ext и product версии ver+1 (или более поздней).

Чтобы установить файлы сопоставления с разделами system_ext и product , разработчикам устройств или поставщикам необходимо:

  1. Скопируйте сгенерированные файлы базового сопоставления из разделов ver system_ext и product в их исходное дерево .
  2. При необходимости внесите изменения в файлы сопоставления.
  3. Установите файлы сопоставления с разделами system_ext и product ver+1 (или более поздней).

Например, предположим, что раздел system_ext 202504 содержит один публичный тип данных с именем foo_type . Тогда system_ext/etc/selinux/mapping/202504.cil в разделе system_ext 202504 выглядит следующим образом:

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

Если bar_type добавлен в system_ext 202604 и bar_type должен быть сопоставлен с foo_type для раздела vendor 202504, 202504.cil можно обновить с (typeattributeset foo_type_202504 (foo_type)) до (typeattributeset foo_type_202504 (foo_type bar_type)) и затем установить в раздел system_ext 202604. Раздел vendor 202504 может продолжать получать доступ к foo_type и bar_type раздела system_ext 202604.

Изменения атрибутов для Android 9

Устройства, обновляемые до Android 9, могут использовать следующие атрибуты, однако устройства, запускаемые с Android 9, не должны их использовать.

Атрибуты нарушителя

Android 9 включает следующие атрибуты, связанные с доменом:

  • data_between_core_and_vendor_violators . Атрибут для всех доменов, нарушающих требование запрета на общий доступ к файлам по пути между vendor и coredomains . Процессы платформы и поставщика не должны использовать файлы на диске для взаимодействия (нестабильный ABI). Рекомендация:
    • Код поставщика должен использовать /data/vendor .
    • Система не должна использовать /data/vendor .
  • system_executes_vendor_violators . Атрибут для всех системных доменов (кроме доменов init и shell domains ), которые нарушают требование не выполнять исполняемые файлы вендора. API для выполнения исполняемых файлов вендора нестабилен. Платформа не должна выполнять исполняемые файлы вендора напрямую. Рекомендация:
    • Такие зависимости платформы от двоичных файлов поставщика должны находиться за HIDL HAL.

      ИЛИ

    • coredomains , которым необходим доступ к исполняемым файлам поставщика, следует переместить в раздел vendor и, таким образом, перестать быть coredomain .

Ненадежные атрибуты

Недоверенные приложения, размещающие произвольный код, не должны иметь доступа к службам HwBinder, за исключением тех, которые считаются достаточно безопасными для доступа из таких приложений (см. раздел «Безопасные службы» ниже). Это обусловлено двумя основными причинами:

  1. Серверы HwBinder не выполняют аутентификацию клиентов, поскольку HIDL в настоящее время не раскрывает информацию об UID вызывающего абонента. Даже если бы HIDL раскрывал такие данные, многие службы HwBinder либо работают на уровне ниже уровня приложений (например, HAL), либо не должны полагаться на идентификацию приложения для авторизации. Таким образом, для обеспечения безопасности по умолчанию предполагается, что каждая служба HwBinder считает всех своих клиентов одинаково авторизованными для выполнения операций, предлагаемых службой.
  2. Серверы HAL (подмножество служб HwBinder) содержат код с более высокой частотой возникновения проблем безопасности, чем system/core компоненты, и имеют доступ к нижним уровням стека (вплоть до аппаратного обеспечения), тем самым увеличивая возможности обхода модели безопасности Android.

Безопасные услуги

Безопасные услуги включают в себя:

  • same_process_hwservice . Эти службы (по определению) работают в процессе клиента и, следовательно, имеют тот же доступ, что и домен клиента, в котором работает процесс.
  • coredomain_hwservice . Эти сервисы не представляют рисков, связанных с причиной №2.
  • hal_configstore_ISurfaceFlingerConfigs . Эта служба специально разработана для использования любым доменом.
  • hal_graphics_allocator_hwservice . Эти операции также доступны через службу surfaceflinger Binder, доступ к которой разрешен приложениям.
  • hal_omx_hwservice . Это HwBinder-версия службы mediacodec Binder, к которой приложениям разрешён доступ.
  • hal_codec2_hwservice . Это более новая версия hal_omx_hwservice .

Полезные атрибуты

Все hwservices не считающиеся безопасными, имеют атрибут untrusted_app_visible_hwservice . Соответствующие серверы HAL имеют атрибут untrusted_app_visible_halserver . Устройства с Android 9 НЕ ДОЛЖНЫ использовать ни один из атрибутов untrusted .

Рекомендация:

  • Недоверенные приложения должны вместо этого обращаться к системной службе, которая взаимодействует с HIDL HAL поставщика. Например, приложения могут обращаться к binderservicedomain , а затем mediaserver (который также является binderservicedomain ) в свою очередь обращается к hal_graphics_allocator .

    ИЛИ

  • Приложения, которым необходим прямой доступ к HAL-спискам vendor должны иметь собственный домен sepolicy, определяемый поставщиком.

Тесты атрибутов файлов

Android 9 включает тесты времени сборки , которые гарантируют, что все файлы в определенных местах имеют соответствующие атрибуты (например, все файлы в sysfs имеют требуемый атрибут sysfs_type ).

Маркировка контекстов SELinux

Чтобы обеспечить различие между политикой платформы и поставщика, система создает файлы контекста SELinux по-разному, чтобы сохранить их раздельность.

Контексты файлов

В Android 8.0 внесены следующие изменения для file_contexts :

  • Чтобы избежать дополнительных затрат на компиляцию на устройстве во время загрузки, file_contexts перестают существовать в двоичном виде. Вместо этого они представляют собой читаемые текстовые файлы с регулярными выражениями, такие как {property, service}_contexts (как это было до версии 7.0).
  • file_contexts разделены между двумя файлами:
    • plat_file_contexts
      • file_context платформы Android, не имеющий меток, специфичных для устройства, за исключением маркировки частей раздела /vendor , которые должны быть точно помечены для обеспечения правильного функционирования файлов sepolicy.
      • Должен находиться в system разделе по адресу /system/etc/selinux/plat_file_contexts на устройстве и загружаться init при запуске вместе с file_context поставщика.
    • vendor_file_contexts
      • Специфический для устройства file_context , созданный путем объединения file_contexts , найденных в каталогах, на которые указывает BOARD_SEPOLICY_DIRS в файлах Boardconfig.mk устройства.
      • Должен быть установлен в /vendor/etc/selinux/vendor_file_contexts в разделе vendor и загружаться init в начале вместе с платформой file_context .

Контексты свойств

В Android 8.0 property_contexts разделен на два файла:

  • plat_property_contexts
    • property_context платформы Android, не имеющее меток, специфичных для устройства.
    • Должен находиться в system разделе по адресу /system/etc/selinux/plat_property_contexts и загружаться init в начале вместе с property_contexts поставщика.
  • vendor_property_contexts
    • property_context , специфичный для устройства, создается путем объединения property_contexts найденных в каталогах, на которые указывает BOARD_SEPOLICY_DIRS в файлах Boardconfig.mk устройства.
    • Должен находиться в разделе vendor по адресу /vendor/etc/selinux/vendor_property_contexts и загружаться init при запуске вместе с property_context платформы.

Контексты обслуживания

В Android 8.0 service_contexts разделен между следующими файлами:

  • plat_service_contexts
    • service_context , специфичный для платформы Android, для servicemanager . Контекст service_context не имеет меток, специфичных для устройства.
    • Должен находиться в system разделе по адресу /system/etc/selinux/plat_service_contexts и загружаться servicemanager при запуске вместе с поставщиком service_contexts .
  • vendor_service_contexts
    • service_context , специфичный для устройства, создается путем объединения service_contexts найденных в каталогах, на которые указывает BOARD_SEPOLICY_DIRS в файлах Boardconfig.mk устройства.
    • Должен находиться в разделе vendor по адресу /vendor/etc/selinux/vendor_service_contexts и загружаться servicemanager в начале вместе с платформой service_contexts .
    • Хотя servicemanager ищет этот файл во время загрузки, для полностью совместимого устройства TREBLE файл vendor_service_contexts НЕ ДОЛЖЕН существовать. Это связано с тем, что всё взаимодействие между процессами vendor и system ДОЛЖНО осуществляться через hwservicemanager / hwbinder .
  • plat_hwservice_contexts
    • Платформа Android hwservice_context для hwservicemanager , не имеющая меток, специфичных для устройства.
    • Должен находиться в system разделе по адресу /system/etc/selinux/plat_hwservice_contexts и загружаться hwservicemanager в начале вместе с vendor_hwservice_contexts .
  • vendor_hwservice_contexts
    • Специфический для устройства hwservice_context , созданный путем объединения hwservice_contexts , найденных в каталогах, на которые указывает BOARD_SEPOLICY_DIRS в файлах Boardconfig.mk устройства.
    • Должен находиться в разделе vendor по адресу /vendor/etc/selinux/vendor_hwservice_contexts и загружаться hwservicemanager в начале вместе с plat_service_contexts .
  • vndservice_contexts
    • service_context , специфичный для устройства, для vndservicemanager , созданный путем объединения vndservice_contexts , найденных в каталогах, на которые указывает BOARD_SEPOLICY_DIRS в Boardconfig.mk устройства.
    • Этот файл должен находиться в разделе vendor по адресу /vendor/etc/selinux/vndservice_contexts и загружаться vndservicemanager при запуске.

Контексты Seaapp

В Android 8.0 seapp_contexts разделен на два файла:

  • plat_seapp_contexts
    • Платформа Android seapp_context , не имеющая специфичных для устройства изменений.
    • Должен находиться в system разделе по адресу /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Специфическое для устройства расширение платформы seapp_context , созданное путем объединения seapp_contexts , найденных в каталогах, на которые указывает BOARD_SEPOLICY_DIRS в файлах Boardconfig.mk устройства.
    • Должен находиться в разделе vendor по адресу /vendor/etc/selinux/vendor_seapp_contexts .

MAC-разрешения

В Android 8.0 файл mac_permissions.xml разделен на два файла:

  • Платформа mac_permissions.xml
    • Файл mac_permissions.xml для платформы Android, не имеющий изменений, специфичных для устройства.
    • Должен находиться в system разделе по адресу /system/etc/selinux/.
  • Неплатформенный mac_permissions.xml
    • Специфическое для устройства расширение для платформы mac_permissions.xml , созданное на основе mac_permissions.xml , найденного в каталогах, на которые указывает BOARD_SEPOLICY_DIRS в файлах Boardconfig.mk устройства.
    • Должен располагаться в разделе vendor по адресу /vendor/etc/selinux/.