Я знаю, что при рутировании мы выполняем скрипт, и мы используем вещь , которая уже является root, и говорим ей выполнить, если она выполняет скрипт как root, а затем рутирует телефон, так как же SElinux помогает защититься от этого?
Пример Я использовал ядро для выполнения скрипта с правами root, он будет выполняться в домене ядра, который уже является root, поэтому он будет выполнять скрипт с правами root и давать привилегии root, так как же SElinux защищает от этого?
Резюме: Эксплойт — это любой эксплойт в системе для получения root-прав. Скрипт -скрипт — это скрипт, который будет передан в эксплуатируемую область, чтобы он мог выполняться от имени пользователя root и рутировать систему.
Итак, если я воспользуюсь этим и передам сценарий, как SElinux защитит от него?
SELinux зависит от меток для соответствия действиям и политикам. Метки определяют, что разрешено. Сокеты, файлы и процессы имеют метки в SELinux. Решения SELinux в основном основаны на метках, присвоенных этим объектам, и политике, определяющей, как они могут взаимодействовать. В SELinux метка имеет вид: пользователь:роль:тип:mls_level, где тип является основным компонентом решений о доступе, который может быть изменен другими компонентами разделов, составляющими метку. Объекты сопоставляются с классами, а различные типы доступа для каждого класса представлены разрешениями.
Правила политики имеют вид: разрешить типы доменов: разрешения классов;, где:
Домен — метка для процесса или набора процессов. Также называется типом домена, поскольку это просто тип для процесса. Тип — метка для объекта (например, файла, сокета) или набора объектов. Класс — тип объекта (например, файл, сокет), к которому осуществляется доступ. Разрешение — выполняемая операция (например, чтение, запись). И поэтому пример использования этого будет следовать структуре:
разрешить домен приложения app_data_file:file rw_file_perms;
Это говорит о том, что всем доменам приложений разрешено читать и записывать файлы с пометкой app_data_file. Обратите внимание, что это правило основано на макросах, определенных в файле global_macros, и другие полезные макросы также можно найти в файле te_macros, оба из которых можно найти в каталоге external/sepolicy в дереве исходного кода AOSP. Макросы предназначены для общих групп классов, разрешений и правил, и их следует использовать, когда это возможно, чтобы уменьшить вероятность сбоев из-за отказа в соответствующих разрешениях.
В дополнение к индивидуальному перечислению доменов или типов в правиле можно также ссылаться на набор доменов или типов через атрибут. Атрибут — это просто имя для набора доменов или типов. Каждый домен или тип может быть связан с любым количеством атрибутов. Когда написано правило, определяющее имя атрибута, это имя автоматически расширяется до списка доменов или типов, связанных с атрибутом. Например, атрибут domain связан со всеми доменами процессов, а атрибут file_type связан со всеми типами файлов.
Используйте приведенный выше синтаксис для создания правил avc, составляющих основу политики SELinux. Правило принимает вид:
<rule variant> <source_types> <target_types> : <classes> <permissions>
Правило указывает, что должно произойти, когда субъект, помеченный любым из source_types, попытается выполнить действие, соответствующее любому из разрешений на объект с любым из классов классов, который имеет любую метку target_types. Наиболее распространенным примером одного из этих правил является разрешающее правило, например:
разрешить домен null_device:chr_file {открыть};
Это правило позволяет процессу с любым доменом, связанным с атрибутом «домен», выполнять действие, описанное разрешением «открыть» в отношении объекта класса «chr_file» (файл символьного устройства), который имеет метку target_type «null_device». На практике это правило может быть расширено за счет включения других разрешений:
разрешить домен null_device:chr_file {getattr open read ioctl lock append write};
В сочетании со знанием того, что «домен» — это атрибут, назначаемый всем доменам процессов, и что null_device — это метка для символьного устройства /dev/null, это правило в основном разрешает чтение и запись в /dev/null.
Домен обычно соответствует процессу и будет иметь связанную с ним метку.
Например, типичное приложение для Android работает в собственном процессе и имеет метку untrusted_app, которая предоставляет ему определенные ограниченные разрешения.
Приложения платформы, встроенные в систему, запускаются под отдельной меткой и получают отдельный набор разрешений. Системные приложения с UID, которые являются частью основной системы Android, запускаются под меткой system_app для получения еще одного набора привилегий.
Доступ к следующим общим меткам никогда не должен напрямую разрешаться доменам; вместо этого для объекта или объектов следует создать более конкретный тип:
socket_device устройство block_device default_service system_data_file tmpfs
Источник: концепции SELinux
Подробнее см.: Linux с улучшенной безопасностью в Android.
Реализация SELinux.
лунабат74