Как проверить статус selinux android

Руководство для начинающих по SELinux

Перевод статьи подготовлен для студентов курса «Безопасность Linux»

SELinux или Security Enhanced Linux — это улучшенный механизм управления доступом, разработанный Агентством национальной безопасности США (АНБ США) для предотвращения злонамеренных вторжений. Он реализует принудительную (или мандатную) модель управления доступом (англ. Mandatory Access Control, MAC) поверх существующей дискреционной (или избирательной) модели (англ. Discretionary Access Control, DAC), то есть разрешений на чтение, запись, выполнение.

У SELinux есть три режима:

1. Enforcing — запрет доступа на основании правил политики.
2. Permissive — ведение лога действий, нарушающих политику, которые в режиме enforcing были бы запрещены.
3. Disabled — полное отключение SELinux.

По умолчанию настройки находятся в /etc/selinux/config

Изменение режимов SELinux

Чтобы узнать текущий режим запустите

Для изменения режима на permissive запустите следующую команду

или, для изменения режима с permissive на enforcing, выполните

Если вам нужно полностью отключить SELinux, то это можно сделать только через файл конфигурации

Для отключения измените параметр SELINUX следующим образом:

Настройка SELinux

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

После установки режима permissive, создадим в корне пустой скрытый файл с именем autorelabel

и перезагрузим компьютер

Примечание: мы используем режим permissive для маркировки, поскольку использование режима enforcing может привести к краху системы во время перезагрузки.

Не беспокойтесь, если загрузка застрянет на каком-то файле, маркировка занимает некоторое время. После завершения маркировки и загрузки вашей системы вы можете перейти к файлу конфигурации и установить режим enforcing, а также запустить:

Теперь вы успешно включили SELinux на своем компьютере.

Мониторим логи

Возможно, у вас возникли какие-то ошибки во время маркировки или во время работы системы. Чтобы проверить, работает ли ваш SELinux правильно и не блокирует ли он доступ к какому-либо порту, приложению и т. д. нужно посмотреть логи. Лог SELinux находится в /var/log/audit/audit.log , но вам не нужно читать его целиком, чтобы найти ошибки. Можно использовать утилиту audit2why для поиска ошибок. Запустите следующую команду:

В результате вы получите список ошибок. Если ошибок в логе не было, то никаких сообщений отображаться не будет.

Настройка политики SELinux

Политика SELinux — это набор правил, которыми руководствуется механизм безопасности SELinux. Политика определяет набор правил для конкретного окружения. Сейчас мы изучим как настраивать политики, чтобы разрешить доступ к запрещенным сервисам.

1. Логические значения (переключатели)

Переключатели (booleans) позволяют изменять части политики во время работы, без необходимости создания новых политик. Они позволяют вносить изменения без перезагрузки или перекомпиляции политик SELinux.

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

Эта команда выдаст список доступных переключателей с их текущим состоянием (включено/on или выключено/off) и описанием. Вы можете уточнить поиск, добавив grep, чтобы найти результаты, относящиеся только с ftp:

и найдете следующее

Этот переключатель выключен, поэтому мы включим его с помощью setsebool $ setsebool ftp_home_dir on

Теперь наш ftp-демон сможет получить доступ к домашнему каталогу пользователя.
Примечание: вы также можете получить список доступных переключателей без описания, выполнив getsebool -a

2. Метки и контекст

Это наиболее распространенный способ реализации политики SELinux. Каждый файл, папка, процесс и порт помечаются контекстом SELinux:

• Для файлов и папок метки хранятся как расширенные атрибуты в файловой системе и могут быть просмотрены следующей командой:
• Для процессов и портов маркировкой управляет ядро, и можно посмотреть эти метки следующим образом:

Пример
Теперь давайте рассмотрим пример, чтобы лучше понять метки и контекст. Допустим, у нас есть веб-сервер, который вместо каталога /var/www/html/ использует /home/dan/html/ . SELinux сочтет это нарушением политики, и вы не сможете просматривать ваши веб-страницы. Это потому, что мы не установили контекст безопасности, связанный с HTML-файлами. Для просмотра контекста безопасности по умолчанию используйте следующую команду:

Здесь мы получили httpd_sys_content_t в качестве контекста для html-файлов. Нам нужно установить этот контекст безопасности для нашего текущего каталога, который сейчас имеет следующий контекст:

Альтернативная команда для проверки контекста безопасности файла или каталога:

Мы также будем использовать semanage для изменения контекста, после того как найдем правильный контекст безопасности. Чтобы изменить контекст /home/dan/html, выполните следующие команды:

После того, как контекст изменен с помощью semanage, команда restorecon загрузит контекст по умолчанию для файлов и каталогов. Наш веб-сервер теперь сможет читать файлы из папки /home/dan/html , поскольку контекст безопасности для этой папки был изменен на httpd_sys_content_t .

3. Создание локальных политик

Могут возникнуть ситуации, когда вышеуказанные методы бесполезны для вас, и вы получаете ошибки (avc/denial) в audit.log. Когда такое происходит, то нужно создать локальную политику (Local policy). Все ошибки вы можете найти с помощью audit2why, как было описано выше.

Для устранения ошибок можно создать локальную политику. Например, мы получаем ошибку, связанную с httpd (apache) или smbd (samba), мы grep’аем ошибки и создаем для них политику:

Здесь http_policy и smb_policy — это названия локальных политик, которые мы создали. Теперь нам нужно загрузить эти созданные локальные политики в текущую политику SELinux. Это можно сделать следующим образом:

Наши локальные политики были загружены, и мы не должны больше получать никаких avc или denail в audit.log.

Это была моя попытка помочь вам понять SELinux. Я надеюсь, что после прочтения этой статьи вы будете чувствовать себя с SELinux более комфортно.

Источник

Русские Блоги

Подробное описание selinux для Android

SELinux — это Linux с усиленной безопасностью. Он был инициирован Агентством национальной безопасности (NSA), Secure Computing Corporation (SCC) и MITER непосредственно участвовал в разработке, а многие исследовательские институты (например, Университет Юты) участвовали в механизме обязательной проверки безопасности. Как программное обеспечение общего доступа, оно было выпущено в декабре 2000 г. (код выпущен под лицензией GPL). А после Linux Kernel 2.6 он был напрямую интегрирован в SELinux и построен на основе Linux Security Module (LSM) и стал самым популярным и наиболее широко используемым решением безопасности. SEAndroid — это набор механизмов безопасности системы, основанный на SELinux, который Google официально запустил для Android 4.4.

1. Базовые знания

Теоретически процесс имеет те же разрешения, что и пользователь, который его выполняет. Например, если вы запускаете браузер от имени пользователя root, браузер имеет полномочия пользователя root и может делать что угодно в системе Linux. То есть, как и в версии до 4.4, пока мы даем узлу достаточно разрешений, мы можем выполнять произвольные операции по желанию.

Linux DAC имеет очевидные недостатки. Одним из важных моментов является то, что права root являются «незаконными» и могут делать почти все. Как только злоумышленник получает права root, он получает полный контроль над системой. Кроме того, каждый процесс получает все разрешения, соответствующие этому пользователю по умолчанию, и может изменять / удалять все файловые ресурсы этого пользователя, что, очевидно, сложно предотвратить вредоносным ПО. Следовательно, новая модель безопасности разрабатывается вне DAC, называемая MAC (обязательный контроль доступа), принудительный контроль доступа, то есть система строго ограничивает каждый доступ, а конкретная стратегия ограничения предоставляется разработчиком. Философия MAC очень проста: то есть любой процесс, который хочет делать что-либо в системе SELinux, должен сначала предоставить разрешения в файле конфигурации политики безопасности. Если разрешение не отображается в файле конфигурации политики безопасности, процесс не имеет разрешения.

Ввиду недостатков DAC LinuxMAC требует, чтобы система проводила целевую проверку для каждого доступа и каждого доступа к файловому ресурсу. И эта целевая проверка основана на определенной стратегии. В ядре Linux все механизмы MAC построены на основе модулей безопасности Linux (LSM), включая SELinux, Apparmor, Smack и TOMOYOLinux. В настоящее время SELinux стал де-факто отраслевым стандартом.
Для Linux DAC, MAC, очевидно, может компенсировать недостатки DAC. С одной стороны, права root ограничены. Даже если у вас есть права root, если вы не можете пройти проверку MAC, вы действительно не сможете выполнять связанные операции. Кроме того, каждая власть была уточнена более полно, что может ограничивать доступ пользователей к ресурсам.

2. Разработка SELinux и SEAndroid

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

SELinux обеспечивает Android следующими эффектами:

Полномочия ROOT строго ограничены, и ситуация с «беспределом» ROOT в прошлом будет значительно улучшена.
* Благодаря защите SELinux снижается риск атаки на критические системные процессы. Обычные процессы не будут иметь разрешения на прямое подключение к критическим системным процессам.
* Дальнейшее усиление механизма песочницы APP, чтобы приложение не могло выполнять ненормальное или агрессивное поведение.
* Это изменит историю, что после установки приложения разрешения уже мертвы, и станет возможной динамическая настройка разрешений приложения.

3. Базовая архитектура и принципы SElinux и SEAndroid

SELinux — это типичная реализация MAC, которая генерирует контекст безопасности (контекст безопасности) для каждого объекта в системе, и каждый объект, обращающийся к ресурсам системы, должен пройти проверку контекста безопасности. Правила аудита включают принудительное применение типов, многоуровневую безопасность и управление доступом на основе ролей (RBAC).

Общая структура SELinux показана на рисунке ниже:

SELinux состоит из пяти основных компонентов:

* Вспомогательный модуль, используемый для обработки файловой системы, а именно SELinuxFS.
* Интеграция наборов перехватчиков модулей безопасности Linux.
* Security Policy Database。
* Модуль проверки метки безопасности.
* Доступ к векторному кэшу (AVC) для доступа к векторному кешу для повышения скорости проверки.

SELinux назначает контекст безопасности (Контекст безопасности) всем объектам Linux, который описывается как стандартная строка. Объекты здесь делятся на два типа: объекты доступа и объекты доступа. Субъектом обычно является процесс, обычно процесс, а объект — ресурс, к которому имеет доступ процесс, обычно файл.

Вы можете увидеть контекст файла, выполнив ls -Z на устройстве с включенным механизмом безопасности SEAndroid.

1. u: это также означает пользователя, который представляет пользователя SELinux, создавшего этот файл.

2. object_r: файл — это мертвый объект, и он не может играть какую-либо роль, поэтому в SELinux мертвые объекты используют object_r для представления своей роли.

3. touch_device: тип мертвого объекта и домен процесса фактически означают одно и то же. Он указывает, что типом, соответствующим корневому каталогу, является touch_device.

4. s0: уровень MLS.

Давайте посмотрим на SContext процесса.Также после открытия механизма безопасности SEAndroid вы можете использовать ps -Z для просмотра контекста процесса.

Рисунок 6: Обработка SContext

Крайний левый столбец на рисунке 6 — это SContext процесса. Если взять в качестве примера SContext процесса / system / bin / af7133d, его значение будет u: r: af7133d: s0, где:

1. u означает пользователя. Пользователь SELinux определен в SEAndroid и имеет значение u.

2. r означает роль. Роль — это значение роли, это относительно высокоуровневая и более удобная идея управления разрешениями в SELinux, а именно управление доступом на основе ролей (сокращенно RBAC). Проще говоря, u может принадлежать нескольким ролям, и разные роли имеют разные разрешения.

3. af7133d, что означает, что домен, к которому принадлежит процесс, — af7133d. Основная идея управления MAC на самом деле направлена ​​не на вышеупомянутый RBAC, а на так называемый контроль доступа с принудительным применением типа (сокращенно TEAC, обычно представленный TE). Для процесса Тип — это домен. Например, все разрешения, которые есть у домена инициализации, необходимо объяснить с помощью инструкции allow в [Пример 1].

4. S0 относится к механизму многоуровневой безопасности (MLS), разработанному SELinux для нужд военной и образовательной промышленности. Проще говоря, MLS классифицирует процессы и файлы системы, и ресурсы разных уровней должны быть доступны процессам соответствующего уровня.

В SEAndroid определен только один пользователь SELinux u, поэтому пользователем SELinux в контексте безопасности всех процессов и файлов, которые мы видим с помощью команд ps -Z и ls -Z, является u. В то же время SEAndroid определяет только одну роль SELinux r. Следовательно, роль SELinux в контексте безопасности всех процессов, которые мы видим с помощью команды ps-Z, равна r.

Иногда вы можете заметить, что мы использовали команду ps -Z, чтобы увидеть, что контекст безопасности процесса init равен «u: r: init: s0». Согласно приведенному выше анализу, является ли это незаконным контекстом безопасности? Ответ — нет, потому что в другом файле external / sepolicy / init.te тип init объявляется посредством оператора type, а домен устанавливается как атрибут типа init, как показано ниже:

Поскольку init имеет атрибут domain, его можно объединить с пользователем SELinux u и ролью SELinux для формирования юридического контекста безопасности, такого как домен.

Стандартный формат SContext следующий:

1. Пользователь: Пользователь, а не Linux UID.

2. Роль: роль, пользователь может принадлежать к нескольким ролям, и разные роли имеют разные разрешения. Это более высокоуровневая и более удобная идея управления разрешениями в SELinux, а именно управление доступом на основе ролей (управление доступом на основе ролей, именуемое RBAC, SELinux не рекомендуется).

3. Тип: Тип темы или объекта. Основная идея управления MAC на самом деле направлена ​​не на вышеупомянутый RBAC, а на так называемый контроль доступа с принудительным контролем типа (сокращенно TEAC, обычно обозначаемый TE). Для процесса Тип — это домен.

Диапазон: уровень многоуровневой безопасности (MLS). MLS классифицирует процессы и файлы системы, и для доступа к различным уровням ресурсов требуются процессы соответствующих уровней.

Выше мы проанализировали контекст безопасности объекта в механизме безопасности SEAndroid, а затем продолжим анализ политики безопасности в механизме безопасности SEAndroid. Политика безопасности в механизме безопасности SEAndroid описывается на основе контекста безопасности, то есть она определяет, имеет ли субъект полномочия для доступа к объекту через контекст безопасности субъекта и объекта.

Механизм безопасности SEAndroid в основном использует типы в контексте безопасности объекта для определения политик безопасности.Эта политика безопасности называется TypeEnforcement или сокращенно TE. В каталоге external / sepolicy после компиляции всех файлов с суффиксом .te будет создан файл sepolicy. Файл sepolicy будет упакован в ПЗУ и сохранен в корневом каталоге устройства, то есть его путь на устройстве / sepolicy.

Как правило, описание TE находится в device / mediatek / common / sepolicy / и external / sepolicy. SEAndroid определяет 33 файла политик te для системы. Эти 33 файла политик:

Вышеупомянутые 33 файла можно разделить на три категории в соответствии с объектами, на которые нацелены их правила политики: формулировка политики для атрибутов: атрибут — это совокупность нескольких типов с общими характеристиками, включая unlimited.te, Шесть файлов domain.te, CTS.te, bluetooth.te, net.te и file.te в основном являются стратегиями, которые непосредственно формулируются для атрибутов.Эта стратегия для атрибутов аналогична формулированию стратегий для нескольких типов одновременно. Стратегии для домена демона: adbd.te, gpsd.te, netd.te, bluetoothd.te, zygote.te, ueventd.te, installd.te, vold.te, dbusd.te, keystore.te, debuggerd .te, mediaserver.te, rild.te, drmserver.te, surfaceflinger.te, qemud.te, servicemanager.te, su.te, shell.te, wpa_supplicant.te. Эти файлы предназначены для разработки стратегий для процесса демона в системе, и все они имеют соответствующий домен демона . Последние 7 файлов используются для формулирования стратегий для других модулей системы. app.te: в этом файле сторонние приложения, установленные в системе, классифицируются на доверенные приложения и ненадежные приложения, которые представлены разными типами, а затем эти два приложения получают доступ к сети, bluetooth , SDCard, data, cache, binder и т. Д. Установите соответствующие разрешения. system.te: этот файл в основном предназначен для системных приложений и системных серверных процессов. Управление доступом системного приложения к связыванию, файлам системных данных, dalvikcatch, keystone и т. Д., А также системному доступу сервера к сети, Bluetooth, netlink, приложению, связыванию, устройству, файлам данных, сокетам, файлам кеша Дождитесь контроля разрешений. init.te: этот файл объявляет, что init имеет неограниченные разрешения. nfc.te: В этом файле устанавливаются права доступа домена nfc к оборудованию nfc и связанным файлам данных. kernel.te: Этот файл заявляет, что ядро ​​имеет неограниченные разрешения. radio.te: В этом файле определяются права доступа радиодомена к файлам init, rild и другим связанным файлам данных. device.te: В этом файле определены все типы, связанные с устройством, и эти типы сгруппированы в атрибут dev_type.

Для служб безопасности пользовательский сервер Security Server в основном используется для защиты ресурсов пользовательского пространства и для управления контекстом безопасности объектов пространства ядра.Он состоит из службы установки приложений PackageManagerService, демона установки приложения installd и процесса приложения. Процесс инкубатора Zygote и состав процесса инициализации. Среди них PackageManagerService и installd отвечают за создание контекста безопасности каталога данных приложения, процесс Zygote отвечает за создание контекста безопасности процесса приложения, а процесс init отвечает за управление безопасным доступом к свойствам системы.

4. Метод решения проблем SELinux

* [307: logd.auditd]: указывает, что этот ЖУРНАЛ был напечатан auditd;

* Type = 1400: SYSCALL; если type = AVC означает события ядра, type = USER_AVC означает события диспетчера объектов пользовательского пространства;

* avc: denied < write >： field depend on what type of event is being audited.；

* Pid = 4663 comm = «om.zte.engineer»: Если это процесс, pid — это номер процесса, а comm — имя запущенного процесса;

* Scontext = u: r: radio: s0: контекст темы — u: r: radio: s0;

* Tcontext = u: object_r: sysfs: s0: целевой контекст u: object_r: sysfs: s0;

* tclass : the object class of the target/> * permissive: permissive (1)or enforcing (0)。

Примерное значение приведенного выше утверждения: процесс om.zte.engineer использует исходный контекст радио для доступа к типу файлов sysfs и записи файлов, но SELinux запрещает доступ.

1. Извлеките весь журнал avc. Например, adb shell «cat / proc / kmsg | grepavc»> avc_log.txt

2. Используйте инструмент audit2allow для прямого создания политики. Audit2allow -i avc_log.txt может автоматически выводить сгенерированную политику.

3. Добавьте соответствующие политики в правила политики selinux, соответствующие Решению MTK, вы можете добавить их в KK: mediatek / custom / common / sepolicy, L: device / mediatek / common / sepolicy, например
allow zygoteresource_cache_data_file:dir rw_dir_perms;
allow zygote resource_cache_data_file:filecreate_file_perms;
===>mediatek/custom/common/sepolicy/zygote.te (KK)
===> device/mediatek/common/sepolicy/zygote.te (L)

Сделав это, вы можете разрешить zygote выполнять операции создания и чтения / записи для resource_cache_data_file. Обратите внимание, что audit2allow может автоматически и механически преобразовывать журнал в политику, не зная истинного намерения вашей операции. Может возникнуть проблема с расширением разрешений, и часто политика не может быть скомпилирована и передана.

Если вы напрямую конвертируете политику SELinux в соответствии с журналом avc: denied, это часто вызывает проблемы с усилением разрешений. Например, если вы хотите получить доступ к определенному устройству, если устройство не уточняет метку SELinux, Может появиться:

[11281.586780] avc: denied < read write >for pid=1217comm=»mediaserver» name=»tfa9897″ dev=»tmpfs»ino=4385 scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0tclass=chr_file permissive=0
Если вы напрямую конвертируете SELinuxPolicy в соответствии с этим LOG: allowmediaserver device: chr_file ; тогда разрешение mediaserver на чтение и запись на всех устройствах будет освобождено. Чтобы предотвратить это, Google использует оператор neverallow для ограничения, так что при компиляции sepolicy вы не можете ее скомпилировать.

Следующее в основном знакомит с тем, как восполнить то, что не хватает, шаг за шагом, чтобы устранить проблему avc: denied, возьмите в качестве примера приведенный выше журнал avc:

Какие полномочия отсутствуют: полномочия ;

Кому не хватает авторитета: scontext = u: r: radio: s0;

У какого файла нет прав доступа: tcontext = u: object_r: sysfs: s0

Какой тип файла: tclass = file

Решение — добавить его в: radio.te

allow radio sysfs:file write;

В приведенном выше примере мы можем резюмировать общее правило: разрешить определенному scontext иметь определенное разрешение для определенного tcontext.

Итак, вы можете получить универсальную формулу:

Scontext tcontext tclass avc отказано в разрешении

allow radio sysfs : file write

Иногда журнал отклоненных avc не отображается сразу, поэтому проблема может заключаться в том, что вам не будет предложено указать другую проблему с разрешениями, пока вы не решите одну проблему с разрешениями, поэтому иногда нам приходится пробовать по одному и добавлять по одному.

SEAndroid определяет самый базовый тип параметра в политике безопасности в te-файле и в то же время группирует общие типы вместе, чтобы сформировать набор, называемый атрибутом, и выполнение правил политики также может использовать атрибуты в качестве объекта выполнения. SEAndroid определяет в общей сложности 17 атрибутов для всех типов:

Источник