4.11 SELinux

SELinux (Security-Enhanced Linux) обеспечивает усиление защиты путем внесения изменений как на уровне ядра, так и на уровне пространства пользователя, что превращает ее в действительно «непробиваемую» операционную систему. Далее описываются основные принципы, на которых построена работа SELinux, а также их реализация в РЕД ОС.

Введение

В большинстве операционных систем имеются средства управления доступом, которые определяют, может ли определенный объект (пользователь или программа) получить доступ к определенному ресурсу. В системах UNIX применяется разграничительный контроль доступа (discretionary access control, DAC). Этот метод позволяет ограничить доступ к объектам на основе групп, к которым они принадлежат. Например, в GNU/Linux для каждого файла определены владелец, группа, а также указаны права доступа к этому файлу. Правами доступа определяется, кто может получить доступ к файлу, кто может открыть его для чтения, кто может внести в него изменения, кто может запустить этот файл на выполнение. Права доступа определены для трех категорий: пользователь (владелец файла), группа (все пользователи, которые являются членами группы) и другие (все пользователи, которые не являются ни владельцем файла, ни членами группы).
Такое разграничение прав доступа может привести к возникновению ряда проблем из-за того, что программа, в которой может быть обнаружена уязвимость, наследует все права доступа пользователя. Следовательно, она может выполнять действия с тем же уровнем привилегий, какой есть у пользователя (что нежелательно). Вместо того чтобы определять ограничения подобным образом, более безопасно использовать принцип наименьшего уровня привилегий (principle of least privilege), согласно которому программы могут делать только то, что им необходимо для выполнения своих задач, и не более того. Таким образом, даже если в программе будет обнаружена уязвимость, то возможности доступа данной программы будет жестко ограничены. Такой тип контроля называется принудительным управлением доступом (mandatory access control, MAC).

Другим методом управления доступом является управление доступом на основе ролей (role-based access control, RBAC). При использовании RBAC права доступа предоставляются на основе ролей, выдаваемых системой безопасности. Отличие концепции ролей от традиционных групп состоит в том, что группа представляет одного или нескольких пользователей, в то время как роль, хотя она также может быть применена к нескольким пользователям, представляет совокупность полномочий на выполнение определенных действий.
SELinux добавляет в операционную систему GNU/Linux поддержку как MAC, так и RBAC.

Установка

Для установки SELinux требуется установить пакет selinux-policy. Это можно сделать, например, воспользоваться командной строкой с привилегиями root пользователя:

# yum install selinux-policy

После перезагрузки SELinux проиндексирует содержимое жёсткого диска, это может занять некоторое время.
Для настройки SELinux можно использовать различные текстовые редакторы чтобы настроить вручную его файл конфигурации:
/etc/selinux/config.

Утилиты

Утилита audit2allow

Утилита audit2allow создает разрешающие правила политики SELinux из файлов журналов, содержащих сообщения о запрете операций.
Эта утилита сканирует журналы в поиске сообщений, появляющихся, когда система не дает разрешения на операцию. Далее утилита генерирует ряд правил, которые, будучи загруженными в политику, могли бы разрешить эти операции. Однако, данная утилита генерирует только разрешающие правила Type Enforcement (TE). Некоторые отказы в использовании разрешений могут потребовать других изменений политики. Например, добавление атрибута в определение типа, для разрешения существующего ограничения (constraint), добавления разрешающего правила для роли или модификации ограничения (constraint). В случае сомнений для диагностики можно попробовать использовать утилиту audit2why.
Следует с осторожностью работать с выводом данной утилиты, убедившись, что разрешаемые операции не представляют угрозы безопасности. Обычно бывает лучше определить новый домен и/или тип или произвести другие структурные изменения. Лучше избирательно разрешить оптимальный набор операций вместо того, чтобы вслепую применить иногда слишком широкие разрешения, рекомендованные этой утилитой. Некоторые запреты на использование разрешений бывают не принципиальны для приложения. В таких случаях вместо использования разрешительного правила («allow» rule) лучше просто подавить журналирование этих запретов при помощи правила «dontaudit».
Синтаксис:

audit2allow [options]
Опция Значение опции
-a | —all Прочесть входную информацию из журналов message и audit. Не используется вместе с опцией -i
-d | —dmesg Прочесть входную информацию из вывода команды /bin/dmesg. Обратите внимание, что когда работает auditd, не все сообщения аудита доступны через dmesg. Вместо этого используйте «ausearch -m avc | audit2allow » или «-a».
-f | —fcfile <File Context File> Добавить Файл Контекстов в генерируемый пакет модуля. Требует опцию -M.
-h | —help Вывести краткую справку по использованию
-i <inputfile> | —input <inputfile> Прочесть входную информацию из <inputfile>
-l | —lastreload Прочесть только часть входной информации, начиная с момента последней перезагрузки политики
-m <modulename> | —module <modulename>  Генерировать модуль. Требуется вывод <modulename>
-M <modulename> Генерировать загружаемый пакет модуля. Опция конфликтует с -o
-o <outputfile> | —output <outputfile> Дописать вывод в <outputfile>
-r | —requires Генерировать вывод в синтаксисе загружаемого модуля.
-R | —reference Генерировать эталонную политику (reference policy), используя установленные макросы. Требуется пакет selinux-policy-devel.
-t | —tefile Указывает, что выходной файл является te-файлом (type enforcement). Может использоваться для конвертации старого формата политик в новый формат.
-v | —verbose Включить подробный вывод
Пример:
Этот пример подходит для системы, использующей пакет audit. Если вы не используете пакет audit, сообщения AVC будут появляться в /var/log/messages. В этом случае замените /var/log/audit/audit.log, используемый в примере, на /var/log/messages.
Использование audit2allow для генерации монолитной (не модульной) политики.
$ cd /etc/selinux/$ SELINUXTYPE/src/policy
$ cat /var/log/audit/audit.log | audit2allow >> domains/misc/local.te
$ cat domains/misc/local.te
allow cupsd_config_t unconfined_t:fifo_file { getattr ioctl };

Просмотрите domains/misc/local.te и измените его

$ make load

Использование audit2allow для генерации модульной политики:

$ cat /var/log/audit/audit.log | audit2allow -m local > local.te
$ cat local.te
module local 1.0;
require {
role system_r;
class fifo_file { getattr ioctl }; type cupsd_config_t; type unconfined_t;};
allow cupsd_config_t unconfined_t:fifo_file { getattr ioctl };

Просмотрите local.te и измените его.
Создание модуля политики вручную:
Скомпилируйте модуль:

$ checkmodule -M -m -o local.mod local.te

Создайте пакет:

$ semodule_package -o local.pp -m local.mod

Загрузите модуль в ядро:

$ semodule -i local.pp

Использование audit2allow для генерации и создания модуля политики:

$ cat /var/log/audit/audit.log | audit2allow -M local

Создается новый type enforcment файл: local.te.
Компиляция политики:

checkmodule -M -m -o local.mod local.te

Создание пакета:

semodule_package -o local.pp -m local.mod

Для того чтобы загрузить только что созданный пакет политики в ядро, вам необходимо выполнить команду

semodule -i local.pp.

Утилита secon

Утилита secon — просмотреть контекст SELinux для файла, программы или ввода пользователя.
Просматривает часть контекста. Контекст берется из файла, идентификатора процесса, ввода пользователя или контекста, в котором была запущена утилита secon.
Синтаксис:

secon [-hVurtscmPRfLp] [CONTEXT] [--file] FILE [--link] FILE [--pid] PID

Опции:

Опция >Значение опции
-V, —version Посмотреть текущую версию secon
-h, —help Вывести информацию по использованию secon
-P, —prompt Вывести данные в формате, подходящем для подсказки
-u, —user Показать пользователя контекста безопасности
-r, —role Показать роль контекста безопасности
-t, —type Показать тип контекста безопасности
-s, —sensitivity Показать уровень чувствительности (sensitivity level) контекста безопасности
-c, —clearance Показать уровень допуска (clearance level) контекста безопасности
-m, —mls-range Показать для контекста безопасности в виде диапазона уровень чувствительности (sensitivity level) и уровень допуска (clearance)
-R, —raw Вывести уровень чувствительности (sensitivity level) и уровень допуска (clearance) в формате без трансляции
-f, —file Получить контекст заданного файла FILE
-L, —link Получить контекст заданного файла FILE (не следовать по символическим ссылкам)
-p, —pid Получить контекст заданного процесса по идентификатору PID
—pid-exec Получить exec контекст заданного процесса по идентификатору PID
—pid-fs Получить fscreate контекст заданного процесса по идентификатору PID
—current, —self Получить контекст из текущего процесса
—current-exec, —self-exec Получить exec контекст из текущего процесса
—current-fs, —self-fs Получить fscreate контекст из текущего процесса
—parent Получить контекст из родительского процесса текущего процесса
—parent-exec Получить exec контекст из родительского процесса текущего процесса
—parent-fs Получить fscreate контекст из родительского процесса текущего процесса

Если не было задано опций, то для того, чтобы secon получил контекст из другого источника, может быть задан дополнительный аргумент CONTEXT. Если этим аргументом является знак дефиса (-), то контекст будет прочитан из стандартного ввода. Если аргументов не было заданно, то secon будет пытаться прочитать контекст со стандартного ввода, но только в том случае, если стандартный ввод не терминал (tty). В этом случае secon будет вести себя как будто была передана опция —self .
Если не задана ни одна опция из —user, —role, —type, —level или —mls-range, то все они будут использованы.

Утилита audit2why

Утилита audit2why — определить из сообщения аудита SELinux причину запрета доступа.
Эта утилита обрабатывает сообщения аудита SELinux, принятые со стандартного ввода, и сообщает, какой компонент политики вызвал каждый из запретов. Если задана опция -p, то используется указанная этой опцией политика, в противном случае используется активная политика. Есть три возможные причины запрета доступа:

  • отсутствует или отключено разрешительное TE правило (TE allow rule);
  • нарушение ограничения (a constraint violation);
  • отсутствует разрешительное правило для роли (role allow rule).

В первом случае разрешительное TE правило может присутствовать в политике, но было отключено через булевы атрибуты. Если же разрешительного правила не было, то оно может быть создано при помощи утилиты audit2allow.
Во втором случае могло произойти нарушение ограничения. Просмотрите policy/constraints или policy/mls для того, чтобы определить искомое ограничение. Обычно, проблема может быть решена добавлением атрибута типа к домену.
В третьем случае была произведена попытка сменить роль, при том что не существует разрешительного правила для участвующей при этом пары ролей. Проблема может быть решена добавлением в политику разрешительного правила для этой пары ролей.
Синтаксис:

audit2why [options]
Опция Значение опции
—help Вывести короткую подсказку
-p <policyfile> Указать альтернативный файл политики.

Пример:

$ /usr/sbin/audit2why < /var/log/audit/audit.log
type=KERNEL msg=audit(1115316408.926:336418): avc: denied { getattr } for path=/home/ sds   dev=hda5   ino=1175041   scontext=root:secadm_r: secadm_t:s0-s9:c0.c127
tcontext=user_u:object_r:user_home_dir_t:s0 tclass=dir
Причиной является: Отсутствует или отключено разрешительное TE правило. Разрешительное TE правило может присутствовать в политике, но было отключено через булевы переключатели; проверьте булевы переключатели. Вы можете посмотреть необходимые разрешительные правила, запустив audit2allow и подав это сообщение аудита на ввод.
type=KERNEL msg=audit(1115320071.648:606858): avc: denied { append } for name=.bash_history dev=hda5 ino=1175047 scontext=user_u:user_r:user_t:s1-s9:c0.c127 tcontext=user_u:object_r:user_home_t:s0 tclass=file
Причиной является: Нарушение ограничения. Проверьте policy/constraints. Обычно, для разрешения ограничения необходимо добавить в домен атрибут типа.

Если вы нашли ошибку, выделите текст и нажмите Ctrl+Enter.

Print Friendly, PDF & Email