SELinux - система принудительного контроля доступа

Введение
Установка
Утилита audit2allow
Утилита secon
Утилита audit2why

Окружение

• Версия РЕД ОС: 7.3
• Редакция ОС: Все
• Конфигурация: Рабочая станция

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-пользователя:

dnf install selinux-policy

После перезагрузки SELinux проиндексирует содержимое жёсткого диска, это может занять некоторое время.

Для настройки SELinux можно использовать различные текстовые редакторы чтобы настроить вручную его файл конфигурации:

/etc/selinux/config.

Утилиты

Утилита audit2allow

Утилита audit2allow создает разрешающие правила политики SELinux из файлов журналов, содержащих сообщения о запрете операций.

Эта утилита сканирует журналы в поиске сообщений, появляющихся, когда система не дает разрешения на операцию. Далее утилита генерирует ряд правил, которые, будучи загруженными в политику, могли бы разрешить эти операции. Однако, данная утилита генерирует только разрешающие правила Type Enforcement (TE). Некоторые отказы в использовании разрешений могут потребовать других изменений политики. Например, добавление атрибута в определение типа, для разрешения существующего ограничения (constraint), добавления разрешающего правила для роли или модификации ограничения (constraint). В случае сомнений для диагностики можно попробовать использовать утилиту audit2why.

Следует с осторожностью работать с выводом данной утилиты, убедившись, что разрешаемые операции не представляют угрозы безопасности. Обычно бывает лучше определить новый домен и/или тип или произвести другие структурные изменения. Лучше избирательно разрешить оптимальный набор операций вместо того, чтобы вслепую применить иногда слишком широкие разрешения, рекомендованные этой утилитой. Некоторые запреты на использование разрешений бывают не принципиальны для приложения. В таких случаях вместо использования разрешительного правила («allow» rule) лучше просто подавить журналирование этих запретов при помощи правила «dontaudit».

Синтаксис:

audit2allow 

Опция	Значение опции
-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/policycat /var/log/audit/audit.log | audit2allow >> domains/misc/local.tecat domains/misc/local.teallow 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 

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

Пример:

/usr/sbin/audit2why < /var/log/audit/audit.logtype=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. Обычно, для разрешения ограничения необходимо добавить в домен атрибут типа.

Дата последнего изменения: 14.03.2025

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