Концепции SELinux

Ознакомьтесь с этой страницей, чтобы изучить концепции SELinux.

Обязательный контроль доступа

Security Enhanced Linux (SELinux) — это система обязательного контроля доступа (MAC) для операционной системы Linux. Как система MAC, она отличается от привычной для Linux системы дискреционного контроля доступа (DAC). В системе DAC существует концепция владения, согласно которой владелец определенного ресурса контролирует связанные с ним права доступа. Как правило, это крупнозернистая система, подверженная непреднамеренному повышению привилегий. Система MAC, напротив, обращается к центральному органу для принятия решения по всем попыткам доступа.

SELinux реализован как часть фреймворка Linux Security Module (LSM), который распознает различные объекты ядра и конфиденциальные действия, выполняемые над ними. В момент выполнения каждого из этих действий вызывается функция-перехватчик LSM, определяющая, следует ли разрешить это действие на основе информации, хранящейся в непрозрачном объекте безопасности. SELinux предоставляет реализацию этих перехватчиков и управление этими объектами безопасности, которые в сочетании с собственной политикой определяют решения о доступе.

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

В Android 4.3 и выше SELinux обеспечивает обязательный контроль доступа (MAC) поверх традиционных сред с дискреционным контролем доступа (DAC). Например, для записи на необработанные блочные устройства программное обеспечение обычно должно запускаться от имени пользователя root. В традиционной среде Linux на основе DAC, если учетная запись пользователя root будет скомпрометирована, этот пользователь сможет записывать данные на любое необработанное блочное устройство. Однако SELinux можно использовать для маркировки этих устройств, чтобы процесс, которому назначены привилегии root, мог записывать данные только на те устройства, которые указаны в соответствующей политике. Таким образом, процесс не сможет перезаписать данные и системные настройки за пределами конкретного необработанного блочного устройства.

Дополнительные примеры угроз и способы их устранения с помощью SELinux см. в разделе «Примеры использования» .

Уровни правоприменения

SELinux может быть реализован в различных режимах:

  • Разрешительный режим — политика безопасности SELinux не применяется принудительно, а только регистрируется в журнале.
  • Применение политики безопасности: политика безопасности применяется и регистрируется в журнале. Сбои отображаются как ошибки EPERM.

Этот выбор является бинарным и определяет, будет ли ваша политика предусматривать действия или просто позволит вам выявить потенциальные сбои. Разрешительный режим особенно полезен на этапе внедрения.

Типы, атрибуты и правила

В Android для управления политиками используется компонент Type Enforcement (TE) модуля SELinux. Это означает, что всем объектам (таким как файл, процесс или сокет) присваивается тип . Например, по умолчанию приложение имеет тип untrusted_app . Для процесса его тип также известен как его домен . Можно аннотировать тип одним или несколькими атрибутами . Атрибуты полезны для одновременной ссылки на несколько типов.

Объекты сопоставляются с классами (например, файл, каталог, символическая ссылка, сокет), а различные типы доступа для каждого класса представлены разрешениями . Например, разрешение open существует для класса file . В то время как типы и атрибуты регулярно обновляются в рамках политики Android SELinux, разрешения и классы определены статически и редко обновляются в рамках нового выпуска Linux.

Правило политики имеет вид: allow source target : class permissions ; где:

  • Источник — тип (или атрибут) субъекта правила. Кто запрашивает доступ?
  • Целевой объект — тип (или атрибут) объекта. К чему запрашивается доступ?
  • Класс — тип объекта (например, файл, сокет), к которому осуществляется доступ.
  • Права доступа — выполняемая операция (или набор операций) (например, чтение, запись).

Примером правила может служить следующее:

allow untrusted_app app_data_file:file { read write };

Это означает, что приложениям разрешено читать и записывать файлы с меткой app_data_file . Существуют и другие типы для приложений. Например, isolated_app используется для служб приложений с isolatedProcess=true в их манифесте. Вместо того чтобы повторять правило для обоих типов, Android использует атрибут с именем appdomain для всех типов, охватывающих приложения:

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app appdomain;

allow appdomain app_data_file:file { read write };

Когда в правиле указывается имя атрибута, это имя автоматически разворачивается в список доменов или типов, связанных с этим атрибутом. К числу важных атрибутов относятся:

  • domain — атрибут, связанный со всеми типами процессов.
  • file_type — атрибут, связанный со всеми типами файлов.

Макросы

В частности, при доступе к файлам необходимо учитывать множество типов разрешений. Например, разрешения read недостаточно для открытия файла или вызова stat . Для упрощения определения правил Android предоставляет набор макросов для обработки наиболее распространенных случаев. Например, чтобы включить отсутствующие разрешения, такие как open , приведенное выше правило можно переписать следующим образом:

allow appdomain app_data_file:file rw_file_perms;

Дополнительные примеры полезных макросов см. в файлах global_macros и te_macros . Макросы следует использовать везде, где это возможно, чтобы снизить вероятность сбоев из-за отказов в предоставлении соответствующих прав доступа.

После определения типа его необходимо связать с файлом или процессом, который он представляет. Более подробную информацию о том, как это делается, см. в разделе «Реализация SELinux» . Дополнительную информацию о правилах см. в блокноте SELinux .

Контекст и категории безопасности

При отладке политик SELinux или маркировке файлов (с помощью file_contexts или ls -Z ) вы можете столкнуться с контекстом безопасности (также известным как метка ). Например: u:r:untrusted_app:s0:c15,c256,c513,c768 . Контекст безопасности имеет формат: user:role:type:sensitivity[:categories] . Обычно поля user , role и sensitivity контекста можно игнорировать (см. Specificity ). Поле type объяснено в предыдущем разделе. categories являются частью поддержки многоуровневой безопасности (MLS) в SELinux. В Android 12 и выше категории используются для:

  • Изолируйте данные приложения от доступа со стороны других приложений.
  • Изолируйте данные приложения от одного физического пользователя и перенесите их на другого.

Специфичность

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

  • Большинство политик в AOSP определяются с использованием языка политик ядра (Kernel Policy Language). Есть некоторые исключения, где используется общий промежуточный язык (Common Intermediate Language, CIL).
  • Пользователи SELinux не используются. Единственный определенный пользователь — u . При необходимости физические пользователи представляются с помощью поля categories контекста безопасности.
  • Роли SELinux и управление доступом на основе ролей (RBAC) не используются. Определены и используются две роли по умолчанию: r для субъектов и object_r для объектов.
  • Настройки чувствительности SELinux не используются. Всегда устанавливается чувствительность s0 по умолчанию.
  • Логические значения SELinux не используются. При формировании политики для устройства она не зависит от состояния устройства. Это упрощает аудит и отладку политик.