Google is committed to advancing racial equity for Black communities. See how.
Эта страница переведена с помощью Cloud Translation API.
Switch to English

Реализация SELinux

SELinux настроен на default-deny, что означает, что каждый отдельный доступ, для которого он имеет перехватчик в ядре, должен быть явно разрешен политикой. Это означает, что файл политики содержит большой объем информации о правилах, типах, классах, разрешениях и многом другом. Полное рассмотрение SELinux выходит за рамки этого документа, но понимание того, как писать правила политики, теперь необходимо при создании новых устройств Android. По SELinux уже имеется большой объем информации. Рекомендуемые ресурсы см. В вспомогательной документации .

Ключевые файлы

Чтобы включить SELinux, интегрируйте последнюю версию ядра Android, а затем включите файлы, находящиеся в каталоге system / sepolicy . При компиляции эти файлы составляют политику безопасности ядра SELinux и охватывают вышестоящую операционную систему Android.

В общем, вам не следует изменять файлы system/sepolicy напрямую. Вместо этого добавьте или отредактируйте собственные файлы политик для конкретных устройств в каталоге /device/ manufacturer / device-name /sepolicy . В Android 8.0 и выше изменения, которые вы вносите в эти файлы, должны влиять только на политику в каталоге вашего поставщика. Дополнительные сведения о разделении публичной политики в Android 8.0 и выше см. В разделе Настройка SEPolicy в Android 8.0+ . Независимо от версии Android, вы все равно изменяете эти файлы:

Файлы политики

Файлы, заканчивающиеся на *.te являются исходными файлами политики SELinux, которые определяют домены и их метки. Вам может потребоваться создать новые файлы политики в /device/ manufacturer / device-name /sepolicy , но вы должны попытаться обновить существующие файлы, где это возможно.

Файлы контекста

В файлах контекста вы указываете метки для своих объектов.

  • file_contexts присваивает метки файлам и используется различными компонентами пользовательского пространства. При создании новых политик создавайте или обновляйте этот файл, чтобы присвоить файлам новые метки. Чтобы применить новые file_contexts , перестройте образ файловой системы или запустите restorecon для файла, который нужно изменить. При обновлениях изменения в file_contexts автоматически применяются к разделам system и userdata как часть обновления. Изменения также могут быть автоматически применены при обновлении к другим разделам путем добавления вызовов restorecon_recursive в ваш init. board после того, как раздел был смонтирован для чтения и записи.
  • genfs_contexts назначает метки файловым системам, таким как proc или vfat которые не поддерживают расширенные атрибуты. Эта конфигурация загружается как часть политики ядра, но изменения могут не вступить в силу для inodes ядра, требуя перезагрузки или размонтирования и повторного монтирования файловой системы для полного применения изменений. Определенные метки также могут быть назначены определенным монтированиям, например vfat с помощью параметра context=mount .
  • property_contexts присваивает метки свойствам системы Android, чтобы контролировать, какие процессы могут их устанавливать. Эта конфигурация считывается процессом init во время запуска.
  • service_contexts назначает метки службам service_contexts Android, чтобы контролировать, какие процессы могут добавлять (регистрировать) и находить (искать) ссылку связывания для службы. Эта конфигурация считывается процессом servicemanager во время запуска.
  • seapp_contexts назначает ярлыки процессам приложений и каталогам /data/data . Эта конфигурация считывается процессом zygote при каждом запуске приложения и installd при запуске.
  • mac_permissions.xml назначает тег seinfo приложениям на основе их подписи и, возможно, имени их пакета. Затем тег seinfo можно использовать в качестве ключа в файле seapp_contexts для присвоения определенной метки всем приложениям с этим тегом seinfo . Эта конфигурация читается system_server во время запуска.

Makefile BoardConfig.mk

После редактирования или добавления файлов политики и контекста /device/ manufacturer / device-name /BoardConfig.mk файл makefile /device/ manufacturer / device-name /BoardConfig.mk чтобы он ссылался на подкаталог sepolicy и каждый новый файл политики. Дополнительные сведения о переменных BOARD_SEPOLICY см. В system/sepolicy/README .

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

После восстановления ваше устройство будет включено с SELinux. Теперь вы можете либо настроить политики SELinux для соответствия вашим собственным дополнениям к операционной системе Android, как описано в разделе « Настройка», либо проверить существующие настройки, как описано в разделе « Проверка» .

Когда новые файлы политики и обновления BoardConfig.mk находятся на месте, новые параметры политики автоматически встраиваются в окончательный файл политики ядра. Дополнительные сведения о том, как sepolicy построен на устройстве, см. В разделе Building sepolicy .

Реализация

Чтобы начать работу с SELinux:

  1. Включите SELinux в ядре: CONFIG_SECURITY_SELINUX=y
  2. Измените параметр kernel_cmdline таким образом, чтобы:
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    Это только для начальной разработки политики для устройства. После того, как у вас будет начальная политика начальной загрузки, удалите этот параметр, чтобы ваше устройство использовало принудительное исполнение, иначе CTS выйдет из строя.
  3. Загрузите систему в разрешительном режиме и посмотрите, какие отказы встречаются при загрузке:
    В Ubuntu 14.04 или новее:
    adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
    
    В Ubuntu 12.04:
    adb pull /sys/fs/selinux/policy
    adb logcat -b all | audit2allow -p policy
    
  4. Оцените вывод на предмет предупреждений, похожих на init: Warning! Service name needs a SELinux domain defined; please fix! См. Инструкции и инструменты в разделе « Проверка» .
  5. Определите устройства и другие новые файлы, которые нужно пометить.
  6. Используйте существующие или новые метки для ваших объектов. Взгляните на файлы *_contexts чтобы увидеть, как вещи были ранее помечены, и используйте знания о значениях ярлыков для назначения нового. В идеале это будет существующая метка, которая будет вписываться в политику, но иногда может потребоваться новая метка и правила для доступа к этой метке. Добавьте свои метки в соответствующие файлы контекста.
  7. Определите домены / процессы, у которых должны быть собственные домены безопасности. Вероятно, вам нужно будет написать совершенно новую политику для каждого. Например, все сервисы, порожденные init , должны иметь свои собственные. Следующие команды помогают выявить те, которые продолжают работать (но ВСЕ службы нуждаются в таком лечении):
    adb shell su -c ps -Z | grep init
    
    adb shell su -c dmesg | grep 'avc: '
    
  8. Просмотрите init. device .rc для идентификации любых доменов, у которых нет типа домена. Предоставьте им домен на ранних этапах процесса разработки, чтобы избежать добавления правил в init или иного путаницы при доступе к init с правилами, которые предусмотрены их собственной политикой.
  9. Настройте BOARD_CONFIG.mk для использования переменных BOARD_SEPOLICY_* . См. README в system/sepolicy для получения подробной информации об этом.
  10. Изучите файл init. device .rc и fstab. device и убедитесь, что каждое использование mount соответствует правильно помеченной файловой системе или что указана опция context= mount .
  11. Пройдите по каждому отказу и создайте политику SELinux для правильной обработки каждого из них. См. Примеры в разделе « Настройка» .

Вам следует начать с политик в AOSP, а затем использовать их для собственных настроек. Для получения дополнительной информации о стратегии политики и более подробном рассмотрении некоторых из этих шагов см. Написание политики SELinux .

Сценарии использования

Вот конкретные примеры эксплойтов, которые следует учитывать при создании собственного программного обеспечения и связанных политик SELinux:

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

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

Системные файлы - рассмотрите класс системных файлов, которые должен изменять только системный сервер. Тем не менее, поскольку netd , init и vold запускаются от имени пользователя root, они могут получить доступ к этим системным файлам. Поэтому, если netd скомпрометированным, он может поставить под угрозу эти файлы и, возможно, сам системный сервер.

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

Данные приложения. Другим примером является класс функций, которые должны выполняться от имени пользователя root, но не должны получать доступ к данным приложения. Это невероятно полезно, поскольку могут быть сделаны самые разные утверждения, например, некоторым доменам, не связанным с данными приложения, запрещен доступ в Интернет.

setattr - для таких команд, как chmod и chown , вы можете определить набор файлов, в которых связанный домен может выполнять setattr . Все, кроме этого, может быть запрещено этими изменениями, даже root. Таким образом, приложение может запускать chmod и chown тех, которые помечены как app_data_files но не для shell_data_files или system_data_files .