Концепции SELinux

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

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

Security Enhanced Linux (SELinux) — это система обязательного контроля доступа (MAC) для операционной системы Linux. Как система MAC, она отличается от привычной системы дискреционного управления доступом (DAC) Linux. В системе 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 может быть реализован в различных режимах:

  • Permissive — политика безопасности SELinux не применяется, только регистрируется.
  • Enforcing — политика безопасности применяется и регистрируется. Сбои отображаются как ошибки EPERM.

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

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

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 контекста (см. Специфичность ). Поле type описано в предыдущем разделе. categories являются частью поддержки многоуровневой безопасности (MLS) в SELinux. Начиная с Android S, категории используются для:

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

Специфика

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

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