|
Bog BOS: Механизмы доступа DAC и MAC, SELinux в RHEL |
|
Последние изменения: |
Последнее изменение файла: 2009.08.18
Скопировано с www.bog.pp.ru: 2024.11.21
Традиционный дискреционный механизм доступа (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) и ноль или более категорий.
В ядре 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 представляет собой набор правил в текстовом виде, который компилируется при загрузке. Вместе с дистрибутивом устанавливается уже готовые политики для основных сервисов (более 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 до загрузки политики:
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) с предустановленным набором возможных действий над объектом:
Для смены типа политики (и т.п. действий) необходимо:
touch /.autorelabel перезагрузиться с параметром enforcing=0 подождать обновления контекстов перезагрузиться или "setenforce Enforcing"
Расположение данных
Утилиты (пакеты policycoreutils, setools (дополнительная документация в /usr/share/setools/), libselinux):
В целевой политике используются следующие роли (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:
cd /etc/selinux/targeted/src/policy make reload
Проблемы с 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:
module clamavbog 1.2;
require {
class dir { read search };
class file { getattr read };
type clamd_t;
type proc_t;
type sysctl_kernel_t;
type var_spool_t;
type var_t;
role system_r;
};
allow clamd_t proc_t:file { getattr read };
allow clamd_t sysctl_kernel_t:dir search;
allow clamd_t sysctl_kernel_t:file read;
allow clamd_t var_spool_t:dir read;
allow clamd_t var_spool_t:file { getattr read };
allow clamd_t var_t:dir read;
allow clamd_t var_t:file read;
В тяжёлых случаях можно попробовать утилиту sealert, которая объясняет причины запрета доступа и предлагает готовое решение.
|
Bog BOS: Механизмы доступа DAC и MAC, SELinux в RHEL |
|
Последние изменения: |