@ Карта сайта News Автора!

Bog BOS: Механизмы доступа DAC и MAC, SELinux в RHEL

Последние изменения:
2024.03.28: sysadmin: Файловая система zfs под Linux для архива (обновление от 0.6 до 2.2)

Последнее изменение файла: 2009.08.18
Скопировано с www.bog.pp.ru: 2024.03.29

Bog BOS: Механизмы доступа DAC и MAC, SELinux в RHEL

Механизмы доступа DAC и MAC

Традиционный дискреционный механизм доступа (DAC, Discretionary Access Control) подразумевает наличие владельца у каждого защищаемого объекта. Данный владелец определяет права доступа пользователей к объекту. Каждый процесс (программа) запускается от имени определённого пользователя и права доступа к объектам определяются на основании идентификации субъектов или групп. Субъекты также могут передавать права другим субъектам. В Unix каждый объект представляется файлом. Для каждого файла задаются 3 группы прав: для владельца, для членов своей группы и для всех прочих. В каждую группу входят права на чтение, запись и исполнение (прохождение для файлов-каталогов). Ещё есть дополнительные флаги sticky и suid. POSIX ACL увеличивает гибкость механизма DAC, но не позволяет выйти за его рамки.

Мандатный механизм доступа (MAC, Mandatory Access Control) позволяет задать явные правила доступа субъектов (программ, действующих от имени пользователя) к объектам (файлы, устройства, сокеты, порты, процессы) в виде политики доступа. Политика задаётся не владельцем объекта и не может быть изменена. Права на передачу прав определяются также в политике.

Одним из вариантов мандатного доступа является модель домен-тип. Процесс запускается в поименованном домене безопасности (т.е. имеет определённый уровень доступа), а каждый объект имеет определённый тип (так сказать, уровень секретности). Не надо считать, что один уровень выше другого - ранжирование в общем случае не определено. Политика задаёт список правил, ограничивающий возможности доступа доменов к типам. При каждом обращении к ядру проверяется имеет ли право представитель данного домена на данную операцию к объекту данного типа.

Вариант мандатного доступа - многоуровневая иерархическая система доступа (MLS, Multilevel security). В этой модели уровни доступа и секретности ранжированы. Нельзя читать объекты более высокого уровня секретности и писать в объекты с более низким уровнем секретности - модель Белла-Ла Падула (Bell-La Padula, BLP).

Возможен вариант модели домен-тип или MLS с классификацией данных по тематике (MCS, Multicategory security).

Контекст безопасности (метка, label) есть набор атрибутов безопасности, связанных с субъектом или объектом. В модели MLS/MCS метка безопасности объекта называется секретностью (classification), метка безопасности субъекта называется допуском (clearances) и содержит одно значение чувствительности (sensitivity) и ноль или более категорий.

SELinux как модуль безопасности ядра Linux

В ядре Linux 2.6 был введён механизм интерфейса модулей безопасности (LSM, Linux Security Modules) между ядром и внешним модулем безопасности, который позволяет реализовать дополнительные политики безопасности при обращении приложений к ядру. Внешний модуль вызывается ядром на уровне системных вызовов после проверки прав доступа в соответствии с DAC (identify-based access control, IBAC, по UID).

SELinux реализован как такой модуль безопасности (policy enforcement server), который собирает контексты безопасности субъекта и объекта, обращается к серверу политик для получения решения о разрешении действия и выполняет это решение (при отказе делается запись в журнал аудита SELinux). Сервер политик кеширует часто используемые правила в AVC (access vector cache). При отсутствии решения в кеше он обращается к серверу безопасности, который использует скомпилированный набор политик, загруженный в ядро при инициализации процессом init. Модуль безопасности также занимается записью меток объектов. В ядре 2.6 SELinux (все его части) собирается с ядром статически, не перестав быть модулем LSM. Может работать в режиме предупреждения (permissive, метки файлов продолжают устанавливаться) или реального запрета доступа (enforcing).

Информация о контексте безопасности объектов хранится в расширенных атрибутах (xattrs) в файловой системе (например, ext3), посмотреть их часть можно с помощью ключа "-Z" команды ls. Используется пространство имён "security." и имя атрибута "security.selinux". Посмотреть расширенные атрибуты можно командой: "getfattr -n security.selinux имя-файла", изменить:

chcon -t тип имя-файла
  или 
setfattr -n security.selinux -v "контекст-безопасности\000" имя-файла
  или восстановить контекст по умолчанию политики
restorecon имя-файла

Команда cp по умолчанию создаёт новые файлы с контекстом, определяемым доменом процесса и типом каталога. Если нет специального правила, то контекст просто наследуется от каталога. Контекст можно задать явно ключом "-Z пользователь:роль:тип" или наследовать от исходного файла ключом "-p". Команда mv сохраняет контекст. Архиваторы tar и star могут сохранять и восстанавливать контекст (ключи --xattrs, --acls, --selinux, --no-xattrs, --no-acls, --no-selinux, -H=exustar). Команда mount позволяет задать контекст безопасности для всей файловой системы: "-o context=контекст".

Применение SELinux в RHEL и Fedora

Политика SELinux представляет собой набор правил в текстовом виде, который компилируется при загрузке. Вместе с дистрибутивом устанавливается уже готовые политики для основных сервисов (более 100 тысяч правил). Реализованы модели домен-тип (Type Enforcement, TE), в т.ч. MCS, доступ на основе ролей (role-based access control, RBAC) и MLS.

Основной политикой в Fedora и RHEL (поддерживается только она) является целевая (target) политика (selinux-policy-targeted.noarch), начиная с FC3. Пакет selinux-policy.noarch (selinux-doc.noarch) содержит документацию о политике (/usr/share/doc/selinux-policy-2.4.6/html/index.html). В рамках этой политики описано разрешённое поведение более 200 процессов (в RHEL5). Остальные процессы выполняются в домене unconfined_t (вывод: хотите обойти ограничения SELinux - переименуйте программу). Доступ к объектам в контексте unconfined_t не ограничивается политикой.

При этом init при запуске процесса проверяет значение булевых переменных типа dhcpd_disable_trans, чтобы определить необходимость перевода (transition) сервиса dhcpd из домена unconfined_t в его родной домен при запуске. Значение булевых переменных можно посмотреть и изменить утилитами getsebool и setsebool. Выполняемый файл /usr/sbin/dhcpd при этом имеет тип dhcpd_exec_t (пользователь - system_u, роль - object_r), а процесс переходит в домен dhcpd_t. Переход в другой домен управляется политикой и может происходить при логине, с помощью утилиты newrole, при запуске процесса ("runcon -t домен команда аргументы" или "runcon контекст команда аргументы"). Перевести работающий процесс в новый домен нельзя. При этом в политике определяется в какие домены может переходить субъект с данной ролью. Посмотреть контекст безопасности процессов можно с помощью ключа "-Z" команды ps (или в /proc). Посмотреть контекст своего процесса можно командой id.

Дополнительно для RHEL5 поставляется политика MLS (за отдельные деньги и с ограниченным количеством пакетов, без X Window), selinux-policy-mls.noarch. Данная политика поддерживает модели RBAC (?) и Bell-La Padula. RHEL5 в режиме MLS сертифицирован на EAL4 Augmented with ALC_FLR.3 (LSPP - Labeled Security Protection Profile/EAL4?). В этом режиме команды su/sudo не повышают привилегии, SELinux нельзя отключить или перевести в разрешительный режим, не работают X Windows и многие другие службы.

С помощью этой же политики реализуется модель MCS. В качестве категории можно использовать текстовую строку, затем распределить пользователей по категориям. Пользователи могут метить файлы категориями, которые для них установлены (установить - chcat, посмотреть - "ls -Z"). Файл может быть помечен несколькими категориями, чтобы получить доступ к файлу, пользователь должен быть отнесён ко всем категориям. Проверка производится после проверок DAC и TE. Политики MCS и MLS требуются очень немногим.

Поставляется также "строгая" (strict) политика - всё, что не разрешено, то запрещено (без поддержки), пакет selinux-policy-strict.noarch.

Контекст безопасности в RHEL4 представляется как набор атрибутов пользователь:роль:тип (при задании целевой политики пользователь и роль не используются). Список пользователей можно посмотреть командой "semanage user -l". Пользователь system_u используется для обозначения серверов. Пользователь root - системный администратор. Пользователь user_u - интерактивные пользователи. Кстати, если сервис запускать напрямую, то он будет в контексте user_u, а если с помощью "service ... start", то в контексте system_u. Разница может быть заметна. Пользователь root по умолчанию имеет доступ ко всем категориям. Роль (seinfo --roles) object_r используется для обозначения таких системных объектов, как файлы и устройства. Роль system_r используется для большинства процессов в целевой политике. Определено множество доменов (типов субъектов) и типов (seinfo --types) в зависимости от используемых серверов.

От предыдущих реализаций остались понятия security identifiers (SID, "seinfo --initialsid"), которые используются в процессе init до загрузки политики:

  1. сразу после загрузки ядра запускается процесс init с initial SID
  2. монтирует /proc
  3. init проверяет наличие selinuxfs в ядре, отсутствие ключа загрузки selinux=0 или параметра SELINUX=disabled в /etc/selinux/config
  4. монтирует /selinux
  5. режим применения политики определяется ключом загрузки enforcing= или параметром SELINUX в /etc/selinux/config
  6. init запрашивает версию политики в /selinux/policyvers
  7. считывает название политики из /etc/selinux/config (SELINUXTYPE)
  8. загружает политику из /etc/selinux/имя-политики/policy/policy.номер-версии
  9. использует /etc/selinux/targeted/booleans для модификации булевых переменных
  10. модифицированная политика загружается в ядро
  11. initial SID отбражается в нормальный контекст безопасности (для целевой политики - в user_u:system_r:unconfined_t)
  12. init перезапускает себя, чтобы перейти в домен, определённый в политике (в описании сказано, что для целевой политики остаётся в unconfined_t, но в FC6 и CentOS5 он переходит в init_t по правилу "domain_auto_trans(kernel_t, init_exec_t, init_t", т.е. при запуске программы с контекстом файла init_exec_t в домене kernel_t перевести процесс в домен init_t)

SID также используется для dbus-daemon (system_dbusd_exec_t, system_dbusd_t) и nscd (?).

В RHEL5 в контекст безопасности добавлены текущий уровень доступа (low/current sensitivity) и список категорий, наивысший допустимый уровень доступа (high/clearance) и список категорий для него. Для целевой политики всегда задаётся уровень доступа "s0". Чтобы иметь возможность отличать различных пользователей среди user_u (и распределять их по категориям MCS), вводится понятие SELinux идентификатора (semanage login [-a|-l]). Соответствие между идентификатором категории (от 0 до 1023) задаётся в /etc/selinux/имя-политики/setrans.conf. Посмотреть текущее состояние можно командой "chcat -L". Трансляцией занимается сервис mcstrans (его необходимо перезапускать после редактирования файла).

При описании политики используются классы объектов (seinfo --classes) с предустановленным набором возможных действий над объектом:

Для смены типа политики (и т.п. действий) необходимо:

Расположение файлов в реализации SELinux RHEL и Fedora

Расположение данных

Утилиты

Утилиты (пакеты policycoreutils, setools (дополнительная документация в /usr/share/setools/), libselinux):

Реализация целевой политики (TE)

В целевой политике используются следующие роли (seinfo --roles):

Пользователей SELinux може немного и исключительно для совместимости со строгой политикой (seinfo --users):

Определён всего один уровень доступа - s0.

Определены 1024 абстрактных категории - c0, c1 и т.д. (не используются).

Типы объектов в целевой политике (seinfo --types; ls -Z):

Домены в целевой политике (seinfo --types; ps -Z):

Журнал аудита и пример использования для добавления своих модулей

Журнал аудита собирается системным модулем kauditd и записывается в syslog или перехватывается службой auditd и записывается в специальный файл /var/log/audit/audit.log. По умолчанию записываются только сообщения об ошибках (при описании политики можно использовать команду dontaudit), но можно включить полный аудит параметром "audit=1" при загрузке. В журнал записываются:

Например, странная проблема с syslogd, отзывающаяся на многих других сервисах. При запуске в /var/log/audit/audit.log получаю сообщение об ошибке:

type=AVC msg=audit(1196775407.887:39120): avc:  denied  { read } for  pid=32374 \
    comm="syslogd" name="services" dev=dm-0 ino=3336180 
    scontext=user_u:system_r:syslogd_t:s0 tcontext=user_u:object_r:rpm_script_tmp_t:s0 
    tclass=file

Файл с inode=3336180 (/etc/services) почему-то имеет тип rpm_script_tmp_t вместо etc_t. Восстанавливаем его ("restorecon -v -v /etc/services"), а также файл /etc/hosts и перезапускаем сервис syslog. После этого можно восстановить ранее отключённую целевую политику для сервисов ntpd и apcupsd (и перезапустить их):

setsebool -P syslogd_disable_trans=off
setsebool -P klogd_disable_trans=off
setsebool -P apcupsd_disable_trans=off
setsebool -P ntpd_disable_trans=off

Рассмотрим более сложный случай, когда требования в политике установлены, но restorecon не срабатывает. Например, контекст безопасности для /var/clamav требуется целевой политикой как clamd_etc_t, но restorecon ничего об этом не знает:

restorecon -v -v /etc/freshclam.conf
restorecon -v -v /etc/clamd.conf
restorecon -v -v -r /var/clamav # ничего не делает

Можно посмотреть в исходном тексте политик (пакет selinux-policy-devel, файл /usr/share/selinux/devel/include/services/clamav.if) чего от нас хотят и установить контекст вручную:

setfattr -n security.selinux -v "system_u:object_r:clamd_etc_t:s0\000" /etc/clamd.conf
setfattr -n security.selinux -v "system_u:object_r:clamd_etc_t:s0\000" /etc/clamav.conf
setfattr -n security.selinux -v "system_u:object_r:clamd_etc_t:s0\000" /var/clamav/*
setfattr -n security.selinux -v "system_u:object_r:clamd_etc_t:s0\000" /var/clamav/daily.inc/*
setfattr -n security.selinux -v "system_u:object_r:clamd_var_lib_t:s0\000" /var/clamav

Однако clamav продолжает хотеть чего-то странного от kernel и meminfo, запускается, но не работает, т.к. нет прав к /var/spool/exim/scan/, так что пока просто выключим:

setsebool -P clamd_disable_trans=on

При запуске bind (CentOS5.1, bind-chroot) в /var/log/audit/audit.log получаю сообщение об ошибке:

type=AVC msg=audit(1197375426.821:3914): avc:  denied  { write } for  pid=2521 \
   comm="named" name="bind" dev=dm-0 ino=1925770 \
   scontext=system_u:system_r:named_t:s0 tcontext=user_u:object_r:named_conf_t:s0 tclass=dir

Файл с inode=1925770 (/var/named/chroot/var/log/bind/) имеет в описании тип named_conf_t вместо var_log_t. Устанавливаем контекст вручную (без ":s0" для CentOS4):

setfattr -n security.selinux -v "system_u:object_r:var_log_t:s0\000" /var/named/chroot/var/log
setfattr -n security.selinux -v "system_u:object_r:var_log_t:s0\000" /var/named/chroot/var/log/bind
setfattr -n security.selinux -v "system_u:object_r:named_cache_t:s0\000" /var/named/chroot/var/log/bind/lamers.log

Модификация политики в RHEL4:

Проблемы с MySQL и SSL в CentOS 4.5:

type=AVC msg=audit(1198226100.584:5): avc:  denied  { read } for  pid=3128 
   comm="mysqld" name="ca.crt" dev=dm-0 ino=1081357 
   scontext=user_u:system_r:mysqld_t tcontext=user_u:object_r:tmp_t tclass=file
type=AVC msg=audit(1198226100.585:6): avc:  denied  { read } for  pid=3128 
   comm="mysqld" name="cert.pem" dev=dm-0 ino=10535158 
   scontext=user_u:system_r:mysqld_t tcontext=system_u:object_r:usr_t tclass=lnk_file
type=AVC msg=audit(1198226100.605:7): avc:  denied  { read } for  pid=3128 
   comm="mysqld" name="urandom" dev=tmpfs ino=475 
   scontext=user_u:system_r:mysqld_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file
type=AVC msg=audit(1198226100.606:8): avc:  denied  { read } for  pid=3128 
   comm="mysqld" name="random" dev=tmpfs ino=473 
   scontext=user_u:system_r:mysqld_t tcontext=system_u:object_r:random_device_t tclass=chr_file

Для начала устанавливаем контекст:

setfattr -n security.selinux -v "system_u:object_r:mysqld_db_t\000" ca.crt

Используя audit2allow, выясняем, что в политике не хватает

allow mysqld_t random_device_t:chr_file read;
allow mysqld_t urandom_device_t:chr_file read;

В RHEL5 (FC6) было введено понятие модульности политики (утилита semodule), что позволяет разбить политику на отдельные модули и устанавливать, обновлять и удалять модули (пакеты) политики независимо друг от друга.

Модификация политики в RHEL5:

В тяжёлых случаях можно попробовать утилиту sealert, которая объясняет причины запрета доступа и предлагает готовое решение.

Ссылки

@ Карта сайта News Автора!

Bog BOS: Механизмы доступа DAC и MAC, SELinux в RHEL

Последние изменения:
2024.03.28: sysadmin: Файловая система zfs под Linux для архива (обновление от 0.6 до 2.2)



Copyright © 1996-2024 Sergey E. Bogomolov; www.bog.pp.ru