Концепции 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 Notebook .

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

При отладке политик SELinux или маркировке файлов (с использованием file_contexts или при использовании ls -Z ) вы можете столкнуться с контекстом безопасности (также известным как метка ). Например: 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 не используются. Когда политика создается для устройства, она не зависит от состояния устройства. Это упрощает аудит и отладку политик.