Концепции SELinux

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

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

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

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

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

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

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

Уровни принуждения

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

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

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

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

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

Объекты сопоставляются с классами (например, файл, каталог, символическая ссылка, сокет), а различные виды доступа для каждого класса представлены разрешениями . Например, разрешение open существует для класса file . Хотя типы и атрибуты регулярно обновляются в рамках политики SELinux Android, разрешения и классы определены статически и редко обновляются в рамках нового выпуска 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 Notebook .

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

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

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

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

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

  • Большинство политик в AOSP определены с использованием языка политик ядра. Существуют некоторые исключения, связанные с использованием общего промежуточного языка (CIL).
  • Пользователи SELinux не используются. Определён только один пользователь — u . При необходимости физические пользователи представляются с помощью поля «Категории» контекста безопасности.
  • Роли SELinux и управление доступом на основе ролей (RBAC) не используются. Определены и используются две роли по умолчанию: r для субъектов и object_r для объектов.
  • Чувствительность SELinux не используется. Всегда установлена ​​чувствительность s0 по умолчанию.
  • Булевы значения SELinux не используются. Политика, созданная для устройства, не зависит от его состояния. Это упрощает аудит и отладку политик.