Внедрение SELinux

SELinux настроен на запрет по умолчанию, что означает, что каждый отдельный доступ, для которого у него есть ловушка в ядре, должен быть явно разрешен политикой. Это означает, что файл политики состоит из большого количества информации о правилах, типах, классах, разрешениях и многом другом. Полное рассмотрение SELinux выходит за рамки этого документа, но понимание того, как писать правила политики, теперь необходимо при запуске новых устройств Android. Уже имеется много информации о SELinux. См. вспомогательную документацию для рекомендуемых ресурсов.

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

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

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

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

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

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

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

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

Файл сборки BoardConfig.mk

После редактирования или добавления файлов политики и контекста обновите make /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 на устройстве см. в разделе Построение sepolicy .

Реализация

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

  1. Включить SELinux в ядре: CONFIG_SECURITY_SELINUX=y
  2. Измените параметр kernel_cmdline или bootconfig так, чтобы: 
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    или
    BOARD_BOOTCONFIG := 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. Изучите инициализацию. 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 .