Настройка 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 с открытым исходным кодом .
  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 запрещают поведение, которое никогда не должно происходить. Благодаря тестированию совместимости правила neverallow SELinux теперь применяются на всех устройствах.

Следующие рекомендации призваны помочь производителям избежать ошибок, связанных с правилами 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 , что обеспечивает гарантии безопасности благодаря таким механизмам, как проверенная загрузка. Часто лучшее решение при возникновении проблемы с этим правилом 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:

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

В Android 11 и более поздних версиях разделы system_ext и Product также могут включать политики для конкретных разделов. 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 и продукта не будут смонтированы. Правила в политике безопасности поставщика, использующие OEM-систему system_ext и общедоступную политику продукта, становятся NOP, поскольку определения типов, специфичные для OEM-производителя, отсутствуют.
Примечание. Будьте особенно осторожны при использовании system_ext и общедоступных политик продукта. Публичные политики действуют как экспортируемый API между system_ext/product и поставщиком. Партнеры должны сами решать проблемы совместимости.

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

На устройствах с 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

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

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

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

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

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

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