Начиная с 27 марта 2025 г. мы рекомендуем использовать android-latest-release вместо aosp-main для создания и участия в AOSP. Дополнительные сведения см. в разделе Изменения в AOSP .

Эта страница переведена с помощью Cloud Translation API.

Внедрить SELinux

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

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

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

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

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

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

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

Контекстные файлы — это место, где вы указываете метки для своих объектов.

file_contexts назначает метки файлам и используется различными компонентами пользовательского пространства. При создании новых политик создайте или обновите этот файл, чтобы назначить новые метки файлам. Чтобы применить новый file_contexts , перестройте образ файловой системы или запустите restorecon для файла, который нужно перемаркировать. При обновлениях изменения file_contexts автоматически применяются к разделам системы и пользовательских данных как часть обновления. Изменения также можно автоматически применять при обновлении к другим разделам, добавив вызовы restorecon_recursive в файл init. board .rc после того, как раздел был смонтирован для чтения и записи.
genfs_contexts назначает метки файловым системам, таким как proc или vfat , которые не поддерживают расширенные атрибуты. Эта конфигурация загружается как часть политики ядра, но изменения могут не вступить в силу для in-core inodes, требуя перезагрузки или размонтирования и повторного монтирования файловой системы для полного применения изменений. Определенные метки также могут быть назначены определенным монтированиям, таким как 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. Эти пространства имен применяются демоном keystore2 . Keystore всегда предоставлял пространства имен на основе UID/AID. Keystore 2 дополнительно применяет пространства имен, определенные sepolicy. Подробное описание формата и соглашений этого файла можно найти здесь .

BoardConfig.mk make-файл

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

Выполнение

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

Включить SELinux в ядре: CONFIG_SECURITY_SELINUX=y
Измените параметр kernel_cmdline или bootconfig таким образом, чтобы:
```
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
```
или
```
BOARD_BOOTCONFIG := androidboot.selinux=permissive
```
Это только для начальной разработки политики для устройства. После того, как у вас есть начальная политика загрузки, удалите этот параметр, чтобы ваше устройство применяло enforcing или не проходило CTS.
Загрузите систему в разрешительном режиме и посмотрите, какие запреты возникнут при загрузке:
В 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
```
Оцените вывод на наличие предупреждений, похожих init: Warning! Service name needs a SELinux domain defined; please fix! Инструкции и инструменты см. в разделе Проверка .
Определите устройства и другие новые файлы, которым необходимо присвоить метки.
Используйте существующие или новые метки для своих объектов. Посмотрите на файлы *_contexts чтобы увидеть, как объекты были помечены ранее, и используйте знание значений меток, чтобы назначить новую. В идеале это существующая метка, которая вписывается в политику, но иногда нужна новая метка и правила доступа к этой метке. Добавьте свои метки в соответствующие файлы контекста.
Определите домены/процессы, которые должны иметь свои собственные домены безопасности. Вероятно, вам нужно будет написать совершенно новую политику для каждого. Все службы, порожденные из init , например, должны иметь свою собственную. Следующие команды помогают выявить те, которые остаются запущенными (но ВСЕМ службам нужна такая обработка):
```
adb shell su -c ps -Z | grep init
```
```
adb shell su -c dmesg | grep 'avc: '
```
Просмотрите init. device .rc , чтобы определить любые домены, которые не имеют типа домена. Дайте им домен на ранней стадии процесса разработки, чтобы избежать добавления правил в init или иного смешения доступа init с теми, которые находятся в их собственной политике.
Настройте BOARD_CONFIG.mk для использования переменных BOARD_SEPOLICY_* . Подробности настройки см. в README в system/sepolicy
Проверьте файлы device и device и убедитесь, что каждое использование mount соответствует правильно помеченной файловой системе или что указана опция context= mount .
Пройдитесь по каждому отказу и создайте политику SELinux для правильной обработки каждого. Смотрите примеры в разделе Настройка .

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

Варианты использования

Вот конкретные примеры эксплойтов, которые следует учитывать при создании собственного программного обеспечения и связанных с ним политик 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 .