Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

Настройка SELinux

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

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

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

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

И не забывайте:

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

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

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

Это же утверждение можно записать с *_file_perms макросов 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 является перемещение кода, neverallow проблемы, в раздел /system .

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

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

Политика размещения

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

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

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

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

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

вендоры только для изображений

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

Как и в случае устройств, запускаемых с предыдущими версиями Android, добавьте индивидуальную настройку device/ manufacturer / device-name /sepolicy в 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.

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

Пример: новый, не AOSP HAL для использования расширенными клиентами, которые также существуют в образе системы 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/public типы и атрибуты, необходимые для функциональности). Хотя политика может быть включена в политику для конкретного устройства, она не сможет использовать другие system/sepolicy/private типы system/sepolicy/private типы или изменить (любым способом, влияющим на политику) в результате обновления только для инфраструктуры. Политика может быть изменена в OTA только для платформы, но не будет присутствовать при использовании образа системы AOSP (в котором также не будет нового системного компонента).

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

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

Как и в примере с расширениями AOSP , политика взаимодействия между системой и поставщиком должна device/ manufacturer / device-name /sepolicy каталоге 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 только для платформы

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

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

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

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