Настройка SELinux

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

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

Приступая к настройке SELinux, не забудьте:

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

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

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

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

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

Чтобы предотвратить ненужные проблемы, лучше быть слишком широким и чрезмерно совместимым, чем слишком ограничивающим и несовместимым, что приводит к нарушению функций устройства. И наоборот, если ваши изменения принесут пользу другим, вы должны отправить изменения в политику 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;
См. man-страницу для ptrace . Возможность sys_ptrace дает возможность ptrace любой процесс, что позволяет в значительной степени контролировать другие процессы и должно принадлежать только определенным системным компонентам, указанным в правиле. Необходимость в этой возможности часто указывает на наличие чего-то, что не предназначено для пользовательских сборок или функций, которые не нужны. Удалите ненужный компонент.

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

Настройка SEPolicy в Android 8.0+

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

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

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

В Android 8.0 и более поздних версиях политика существует в следующих местах AOSP:

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

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

  • SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS . Включает политику, экспортированную для использования в политике конкретного поставщика. Устанавливается в раздел system_ext.
  • SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS . Включает в себя политику, необходимую для функционирования образа system_ext, но политика образа какого поставщика не должна знать. Устанавливается в раздел system_ext.
  • PRODUCT_PUBLIC_SEPOLICY_DIRS . Включает политику, экспортированную для использования в политике конкретного поставщика. Установлен в раздел продукта.
  • PRODUCT_PRIVATE_SEPOLICY_DIRS . Включает политику, необходимую для функционирования образа продукта, но о которой политика образа поставщика не должна знать. Установлен в раздел продукта.
Примечание. При использовании GSI разделы OEM system_ext и продукта не монтируются. Правила в sepolicy поставщика, использующие system_ext OEM и общедоступную политику продукта, становятся NOP, поскольку отсутствуют определения типов OEM.
Примечание. Будьте особенно осторожны при использовании общедоступных политик system_ext и продукта. Публичные политики действуют как экспортируемый API между system_ext/product и vendor. Предполагается, что партнеры сами решают проблемы совместимости.

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

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

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

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

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

поддержка vendor-image для работы с 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.

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

Пример: новый HAL, не относящийся к AOSP, для использования расширенными клиентами, которые также существуют в образе системы 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 (в котором также не будет нового системного компонента).

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

Пример: добавление нового 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 только для платформы.