Настройка SELinux

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

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

Приступая к настройке SELinux, помните:

• Написать политику SELinux для всех новых демонов
• Используйте предопределенные домены, когда это уместно
• Назначьте домен любому процессу, запущенному как служба init
• Ознакомьтесь с макросами перед написанием политики
• Отправьте изменения в основную политику в AOSP

И помните, что нельзя:

• Создать несовместимую политику
• Разрешить настройку политики конечного пользователя
• Разрешить настройку политики MDM
• Запугивать пользователей нарушениями политики
• Добавить бэкдоры

Конкретные требования см. в разделе «Функции безопасности ядра» документа «Определение совместимости Android» .

SELinux использует подход белого списка, то есть весь доступ должен быть явно разрешен в политике, чтобы быть предоставленным. Поскольку политика SELinux по умолчанию Android уже поддерживает Android Open Source Project, вам не нужно изменять настройки SELinux каким-либо образом. Если вы настраиваете настройки SELinux, будьте очень осторожны, чтобы не сломать существующие приложения. Чтобы начать:

1. Используйте последнюю версию ядра Android .
2. Принять принцип наименьших привилегий .
3. Обращайтесь только к своим собственным дополнениям к Android. Политика по умолчанию работает с кодовой базой Android Open Source Project автоматически.
4. Разделите компоненты программного обеспечения на модули, которые выполняют отдельные задачи.
5. Создайте политики SELinux, которые изолируют эти задачи от несвязанных функций.
6. Поместите эти политики в файлы *.te (расширение исходных файлов политик SELinux) в каталоге /device/ manufacturer / device-name /sepolicy и используйте переменные BOARD_SEPOLICY , чтобы включить их в сборку.
7. Делать новые домены изначально разрешительными. Это делается с помощью разрешающей декларации в файле .te домена.
8. Проанализируйте результаты и уточните определения домена.
9. Удалите разрешающее объявление, если в сборках userdebug больше не будет отказов.

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

Когда вы начнете настраивать SELinux, сначала проверьте свои дополнения к Android. Если вы добавили компонент, который выполняет новую функцию, убедитесь, что компонент соответствует политике безопасности Android, а также любой связанной политике, созданной OEM, прежде чем включать режим enforcing.

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

Примеры заявлений о политике

SELinux основан на компьютерном языке M4 и поэтому поддерживает множество макросов для экономии времени.

В следующем примере всем доменам предоставляется доступ на чтение или запись в /dev/null и чтение из /dev/zero .

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

Это же выражение можно записать с помощью макроса SELinux *_file_perms (сокращенно):

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

Пример политики

Вот полный пример политики для DHCP, который мы рассмотрим ниже:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

Давайте разберем пример:

В первой строке, объявлении типа, демон DHCP наследует базовую политику безопасности ( domain ). Из предыдущих примеров операторов DHCP может читать и записывать в /dev/null .

Во второй строке DHCP определен как разрешающий домен.

В строке init_daemon_domain(dhcp) политика гласит, что DHCP создается из init и ему разрешено взаимодействовать с ним.

В строке net_domain(dhcp) политика позволяет DHCP использовать общие сетевые функции из домена net , такие как чтение и запись пакетов TCP, связь через сокеты и выполнение DNS-запросов.

В строке allow dhcp proc_net:file write; политика гласит, что DHCP может записывать в определенные файлы в /proc . Эта строка демонстрирует детальную маркировку файлов SELinux. Она использует метку proc_net для ограничения доступа на запись только файлами в /proc/sys/net .

Последний блок примера, начинающийся с allow dhcp netd:fd use; показывает, как приложениям может быть разрешено взаимодействовать друг с другом. Политика гласит, что DHCP и netd могут взаимодействовать друг с другом через файловые дескрипторы, файлы FIFO, сокеты датаграмм и потоковые сокеты UNIX. DHCP может только читать и записывать данные из сокетов датаграмм и потоковых сокетов UNIX, но не создавать или открывать их.

Доступные элементы управления

ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton

add_name remove_name reparent search rmdir open audit_access execmod

ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind

mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget

fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate

compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy

chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

никогда не разрешать правила

Правила SELinux neverallow запрещают поведение, которое никогда не должно происходить. Благодаря тестированию на совместимость правила SELinux neverallow теперь применяются на всех устройствах.

Следующие рекомендации призваны помочь производителям избежать ошибок, связанных с правилами neverallow во время настройки. Номера правил, используемые здесь, соответствуют Android 5.1 и могут быть изменены к выпуску.

Правило 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
См. страницу руководства ptrace . Возможность sys_ptrace предоставляет возможность ptrace любого процесса, что обеспечивает большой контроль над другими процессами и должно принадлежать только назначенным системным компонентам, указанным в правиле. Необходимость в этой возможности часто указывает на наличие чего-то, что не предназначено для сборок, ориентированных на пользователя, или функциональности, которая не нужна. Удалите ненужный компонент.

Правило 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
Это правило предназначено для предотвращения выполнения произвольного кода в системе. В частности, оно утверждает, что выполняется только код в /system , что позволяет гарантировать безопасность благодаря таким механизмам, как Verified Boot. Часто лучшим решением при возникновении проблемы с этим правилом neverallow является перемещение вредоносного кода в раздел /system .

Настройте SEPolicy в Android 8.0 и выше

В этом разделе приведены рекомендации по политике SELinux поставщика в Android 8.0 и выше, включая сведения о SEPolicy и расширениях SEPolicy Android Open Source Project (AOSP). Для получения дополнительной информации о том, как политика SELinux поддерживается в совместимых разделах и версиях Android, см. Совместимость .

Размещение политики

В Android 7.0 и более ранних версиях производители устройств могли добавлять политику в BOARD_SEPOLICY_DIRS , включая политику, предназначенную для расширения политики AOSP на различных типах устройств. В Android 8.0 и более поздних версиях добавление политики в BOARD_SEPOLICY_DIRS помещает политику только в образ поставщика.

В Android 8.0 и выше политика существует в следующих местах AOSP:

• system/sepolicy/public. Включает политику, экспортированную для использования в политике, специфичной для поставщика. Все попадает в инфраструктуру совместимости Android 8.0. Публичная политика должна сохраняться между выпусками, поэтому вы можете включить что угодно /public в свою настраиваемую политику. Из-за этого тип политики, которая может быть размещена в /public , более ограничен. Считайте это API экспортированной политики платформы: все, что имеет дело с интерфейсом между /system и /vendor относится сюда.
• system/sepolicy/private. Включает политику, необходимую для функционирования образа системы, но о которой поставщик политики образа не должен знать.
• system/sepolicy/vendor. Включает политику для компонентов, которые находятся в /vendor но существуют в дереве основной платформы (не в каталогах, специфичных для устройств). Это артефакт различия системы сборки между устройствами и глобальными компонентами; концептуально это часть политики, специфичной для устройств, описанной ниже.
• device/ manufacturer / device-name /sepolicy. Включает политику, специфичную для устройства. Также включает настройки устройства для политики, которая в Android 8.0 и выше соответствует политике для компонентов в образе поставщика.

В Android 11 и более поздних версиях разделы system_ext и product также могут включать политики, специфичные для раздела. Политики system_ext и product также делятся на публичные и частные, и поставщики могут использовать публичные политики system_ext и product, как и системную политику.

• SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS . Включает политику, экспортированную для использования в политике поставщика. Устанавливается в раздел system_ext.
• SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS . Включает политику, необходимую для функционирования образа system_ext, но о которой политика образа поставщика не должна знать. Устанавливается в раздел system_ext.
• PRODUCT_PUBLIC_SEPOLICY_DIRS . Включает политику, экспортированную для использования в политике поставщика. Устанавливается в раздел продукта.
• PRODUCT_PRIVATE_SEPOLICY_DIRS . Включает политику, необходимую для функционирования образа продукта, но о которой политика образа поставщика не должна знать. Устанавливается в раздел продукта.

Поддерживаемые сценарии политики

На устройствах, запускаемых с Android 8.0 и выше, образ поставщика должен работать с образом системы OEM и эталонным образом системы AOSP, предоставленным Google (и проходить CTS на этом эталонном образе). Эти требования обеспечивают четкое разделение между фреймворком и кодом поставщика. Такие устройства поддерживают следующие сценарии.

расширения только для изображений поставщиков

Пример: добавление новой службы в vndservicemanager из образа поставщика, которая поддерживает процессы из образа поставщика.

Как и в случае с устройствами, запускаемыми с предыдущими версиями Android, добавьте специфичную для устройства настройку в device/ manufacturer / device-name /sepolicy . Новая политика, регулирующая взаимодействие компонентов поставщика с (только) другими компонентами поставщика , должна включать типы, присутствующие только в device/ manufacturer / device-name /sepolicy . Политика, написанная здесь, позволяет коду поставщика работать, не будет обновляться как часть OTA только для фреймворка и присутствует в объединенной политике на устройстве с эталонным образом системы AOSP.

Поддержка образов поставщиков для работы с AOSP

Пример: добавление нового процесса (зарегистрированного с помощью hwservicemanager из образа поставщика), который реализует HAL, определенный AOSP.

Как и в случае с устройствами, запускаемыми с предыдущими версиями Android, выполните настройку, специфичную для устройства, в device/ manufacturer / device-name /sepolicy . Политика, экспортированная как часть system/sepolicy/public/ доступна для использования и поставляется как часть политики поставщика. Типы и атрибуты из публичной политики могут использоваться в новых правилах, определяющих взаимодействие с новыми битами, специфичными для поставщика, с учетом предоставленных ограничений neverallow . Как и в случае только для поставщика, новая политика здесь не будет обновляться как часть OTA только для фреймворка и присутствует в объединенной политике на устройстве с эталонным образом системы AOSP.

расширения только для системного образа

Пример: добавление новой службы (зарегистрированной с помощью servicemanager), доступ к которой имеют только другие процессы из образа системы.

Добавьте эту политику в system/sepolicy/private . Вы можете добавить дополнительные процессы или объекты для включения функциональности в образе партнерской системы, при условии, что эти новые биты не должны взаимодействовать с новыми компонентами в образе поставщика (в частности, такие процессы или объекты должны полностью функционировать без политики из образа поставщика). Политика, экспортированная system/sepolicy/public доступна здесь так же, как и для расширений, доступных только для образа поставщика. Эта политика является частью образа системы и может быть обновлена ​​в OTA только для фреймворка, но не будет присутствовать при использовании эталонного образа системы AOSP.

расширения образа поставщика, которые обслуживают расширенные компоненты AOSP

Пример: новый, не-AOSP HAL для использования расширенными клиентами, которые также существуют в образе системы AOSP (например, расширенный system_server).

Политика взаимодействия между системой и поставщиком должна быть включена в каталог device/ manufacturer / device-name /sepolicy поставляемый в разделе поставщика. Это похоже на приведенный выше сценарий добавления поддержки образа поставщика для работы с эталонным образом AOSP, за исключением того, что измененные компоненты AOSP также могут потребовать дополнительной политики для правильной работы с остальной частью системного раздела (что нормально, если у них все еще есть публичные метки типа AOSP).

Политика взаимодействия публичных компонентов AOSP с расширениями, доступными только для образа системы, должна находиться в system/sepolicy/private .

расширения образа системы, которые имеют доступ только к интерфейсам AOSP

Пример: новый системный процесс, не относящийся к AOSP, должен получить доступ к HAL, на который опирается AOSP.

Это похоже на пример расширения system-image-only , за исключением того, что новые системные компоненты могут взаимодействовать через интерфейс system/vendor . Политика для нового системного компонента должна находиться в system/sepolicy/private , что приемлемо при условии, что она проходит через интерфейс, уже установленный AOSP в system/sepolicy/public (то есть, типы и атрибуты, необходимые для функциональности, присутствуют). Хотя политика может быть включена в политику, специфичную для устройства, она не сможет использовать другие типы system/sepolicy/private или изменяться (каким-либо образом, влияющим на политику) в результате обновления только для фреймворка. Политика может быть изменена в OTA только для фреймворка, но не будет присутствовать при использовании образа системы AOSP (который также не будет иметь нового системного компонента).

расширения образа поставщика, которые обслуживают новые системные компоненты

Пример: добавление нового HAL, не относящегося к AOSP, для использования клиентским процессом без аналога AOSP (и, следовательно, требующего собственного домена).

Подобно примеру с расширениями AOSP , политика для взаимодействия между системой и поставщиком должна находиться в каталоге device/ manufacturer / device-name /sepolicy поставляемом в разделе поставщика (чтобы гарантировать, что системная политика не будет знать подробности, специфичные для поставщика). Вы можете добавить новые публичные типы, которые расширяют политику в system/sepolicy/public ; это следует делать только в дополнение к существующей политике AOSP, то есть не удалять публичную политику AOSP. Затем новые публичные типы можно использовать для политики в system/sepolicy/private и в device/ manufacturer / device-name /sepolicy .

Помните, что каждое дополнение к system/sepolicy/public добавляет сложности, предоставляя новую гарантию совместимости, которая должна отслеживаться в файле сопоставления и которая подлежит другим ограничениям. В system/sepolicy/public можно добавлять только новые типы и соответствующие правила разрешения; атрибуты и другие утверждения политики не поддерживаются. Кроме того, новые публичные типы нельзя использовать для прямой маркировки объектов в политике /vendor .

Неподдерживаемые сценарии политики

Устройства с ОС Android 8.0 и выше не поддерживают следующий сценарий политики и примеры.

Дополнительные расширения к системному образу, которым необходимо разрешение на новые компоненты образа поставщика после OTA только для фреймворка

Пример: в следующем выпуске Android добавляется новый системный процесс, не относящийся к AOSP, требующий собственного домена, и ему требуется доступ к новому HAL, не относящемуся к AOSP.

Аналогично взаимодействию новых (не AOSP) системных и вендорных компонентов , за исключением того, что новый тип системы представлен в OTA только для фреймворка. Хотя новый тип может быть добавлен в политику в system/sepolicy/public , существующая политика вендора не имеет сведений о новом типе, поскольку отслеживает только системную публичную политику Android 8.0. AOSP обрабатывает это, предоставляя ресурсы, предоставленные вендором, через атрибут (например, атрибут hal_foo ), но поскольку расширения партнеров атрибутов не поддерживаются в system/sepolicy/public , этот метод недоступен для политики вендора. Доступ должен быть предоставлен ранее существующим публичным типом.

Пример: изменение системного процесса (AOSP или не-AOSP) должно изменить способ его взаимодействия с новым компонентом поставщика, не являющимся AOSP.

Политика в образе системы должна быть написана без знания конкретных настроек поставщика. Политика, касающаяся конкретных интерфейсов в AOSP, таким образом, раскрывается через атрибуты в system/sepolicy/public, чтобы политика поставщика могла подписаться на будущую системную политику, которая использует эти атрибуты. Однако расширения атрибутов в system/sepolicy/public не поддерживаются , поэтому вся политика, определяющая, как системные компоненты взаимодействуют с новыми компонентами поставщика (и которая не обрабатывается атрибутами, уже присутствующими в AOSP system/sepolicy/public ), должна быть в device/ manufacturer / device-name /sepolicy . Это означает, что типы систем не могут изменять доступ, разрешенный для типов поставщиков в рамках OTA только для фреймворка.