LinuxShare

Автор: Андрей Маркелов
Оригинал данного документа расположен по адресу http://markelov.blogspot.com/

SELinux. MLS и MCS: что с чем едят. MCS.

Разберемся, что такое MCS и как ограничить пользователям (в том числе и администратору) доступ к информации при помощи категорий SELinux. Продолжаем разговор, начатый постами: SELinux. Максимальный уровень защиты – бесплатно. и SELinux. MLS и MCS: что с чем едят. MLS.

Итак, если воспользоваться преимуществами многоуровневой системы безопасности (multilevel security - MLS) можно только при использовании «строгой» (strict) политики SELinux, то поддержка мульти-категорийной безопасности (MCS) доступна нам в «целевой» (targeted) политике, используемой по умолчанию. В качестве тестовой машины будем использовать RHEL 5.0, но, по большому счету, это не принципиально. Перечисленные базовые вещи должны одинаково работать на всех последних Fedora/RHEL/CentOS/etc, поставляемых с политикой, собранной из Reference Policy. Выполним команду

[root@dhcppc5 ~]$ seinfo | grep Cat
Sensitivities: 1 Categories: 1024

Мы видим, что нам доступно 1024 категории и один тип чувствительности данных. Что это означает? Вспомним, как выглядел контекст безопасности в FС4 и RHEL4:

user:role:type

Такого контекста безопасности вполне достаточно для организации контроля доступа средствами RBAC и TE. Впрочем, если говорить о работе с целевой политикой, где главный инструмент – TE, пользователь и роль нас особенно не интересует. В MLS политике (а рассматриваемая мульти-категорийная безопасность – это подмножество MLS) контекст расширен и включает два уровня безопасности (security level):

user:role:type: sensitivity[:category,…][- sensitivity[:category,…]]

Первым указывается обязательный текущий уровень (low или current), затем через символ дефиса – наивысший разрешенный уровень (high или clearance). Каждый из двух возможных уровней безопасности включает в себя обязательную часть – чувствительность (sensitivity) данных и ноль или больше категорий (category). Sensitivity в целевой политике всегда будет s0. Чувствительности данных, отличные от 0, зарезервированы для государственных и военных организаций и используются только в политике MLS («секретно», «совершенно секретно» и т.п.). Собственно, то, что нам доступен только один уровень чувствительности и 1024 возможных категорий, мы уже видели в выводе команды seinfo. Кстати, число категорий и чувствительностей данных можно поменять, если вы решите пересобрать политику из исходных кодов. Как и для перекомпиляции ядра, у вас должна быть весомая причина, чтобы этим заниматься. Политика SELinux - модульная, и чаще всего нам приходиться компилировать только отдельные модули. Далее мы не будем касаться работы с sensitivity, а сосредоточимся на категориях.

По умолчанию возможности MCS доступны, но не используются в целевой политике. Все файлы имеют чувствительность s0 и не имеют назначенных категорий. Поэтому если вы в выводе команды ls –Z не видите уровня безопасности, хотя и используете политику с поддержкой MCS, знайте, что он равен s0.Категории обозначаются как с0, с1,… c1024. Для повседневной работы это не очень удобно. Для того чтобы можно было работать с «говорящими» категориями, в Fedora/RHEL по умолчанию запущен демон mcstransd. Он использует конфигурационный файл /etc/selinux/<имя_политики>/setrans.conf. Наиболее «правильным» способом работы с конфигурационными файлами SELinux является использование утилиты semanage, появившейся в Fedora Core 5.

Из man-страницы semanage(8):
semanage используется для настройки некоторых элементов политики SELinux без необходимости модификации или повторной компиляции исходного текста политики. В число таких настроек входит сопоставление имен пользователей Linux пользователям SELinux (которые контролируют исходный контекст безопасности, присваиваемый пользователям Linux во время их регистрации в системе, и ограничивают доступный набор ролей). Также в число настраиваемых элементов входит сопоставление контекстов безопасности для различных видов объектов, таких как: сетевые порты, интерфейсы, сетевые узлы (хосты), а также контексты файлов.

Вводим команду, показывающую существующие имена уровней безопасности:

[root@dhcppc5 ~]# semanage translation -lLevel Translation
s0
s0-s0:c0.c1023 SystemLow-SystemHigh
s0:c0.c1023 SystemHigh

Как и ожидалось, напротив уровня безопасности s0 у нас пробелы, что мы собственно и видим при выводе команды ls –Z. При помощи команды semanege с ключевым словом translation и опциями -a, -d и -m можно добавлять, удалять и модифицировать имена категорий. Пока что после каждого изменения необходимо перезапускать демон mcstransd. В отличие от уровней чувствительности данных, категории не представляют собой иерархической структуры. Точка в синтаксисе обозначает диапазон категорий, запятая отделяет диапазоны и отдельные категории.Теперь посмотрим, к каким категориям разрешен доступ пользователям:

[root@dhcppc5 ~]# semanage login -l

Login Name SELinux User MLS/MCS Range

__default__ user_u s0
root root SystemLow-SystemHigh

Рядовым пользователям по умолчанию разрешен доступ только к s0. Отлично, давайте добавим новую категорию.

[root@dhcppc5 ~]# semanage translation -a -T chaos s0:c20
[root@dhcppc5 ~]# service mcstrans restart

Добавим категорию пользователю. Обратите внимание, что сейчас мы работаем с пользователями Linux (ключевое слово команды login) а не SELinux (ключевое слово user)

[root@dhcppc5 ~]# semanage login -a -r chaos butters

Теперь можно зайти пользователем butters, создать файл в /tmp, и посмотреть, сможет ли пользователь, не имеющий доступ к категории chaos, прочитать этот файл:

[butters@dhcppc5 tmp]$ touch /tmp/butters_file
[cartman@dhcppc5 tmp]$ ls -Z /tmp/butters_file
-rw-rw-r-- butters butters user_u:object_r:tmp_t:chaos /tmp/butters_file
[cartman@dhcppc5 tmp]$ cat /tmp/butters_file
cat: /tmp/butters_file: Permission denied

При этом в /var/log/audit/audit.log мы увидим сообщение:

type=AVC msg=audit(1194279634.604:130): avc: denied { read } for pid=10770 comm="cat" name="butters_file"
dev=dm-0 ino=655970 scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:object_r:tmp_t:s0:c20 tclass=file

Кстати, если воспользоваться утилитой audit2allow:

[root@dhcppc5 ~]# cat /var/log/audit/audit.log | audit2allow -l
allow unconfined_t tmp_t:file read;

мы увидим, что с категориями она работать не умеет, а, значит, от чтения журналов нам все равно не уйти ;) Собственно, это и правильно. audit2allow в первую очередь предназначена для решения проблем с TE.Можно удалить категорию chaos, чтобы позволить остальным доступ к файлу

[butters@dhcppc5 tmp]$ chcat -- -chaos butters_file

Той же самой командой можно добавить категорию для файла. Если файлу назначено несколько категорий (точнее – уровней безопасности), то пользователь должен иметь доступ ко всем категориям для работы с файлом.

При проведении этого маленького эксперимента не пользуйтесь командой su. Заходите с новой консоли или по ssh. Дело в том, что su не меняет текущий SELinux-контекст пользователя:

[cartman@dhcppc5 tmp]$ su -
Password:
[root@dhcppc5 ~]# cat /tmp/butters_file
cat: /tmp/butters_file: Permission denied

Что теперь? А теперь мы используя нашу стандартную целевую политику, которая включена по умолчанию, мы можем запретить системному администратору просмотр не предназначенных для него файлов.В двух словах идея такова:

1. Создаем специальную категорию и специальных пользователей (сотрудников отдела ИБ).
2. Даем доступ к специальной категории только этим специальным пользователям.
3. Присваиваем semanage эту категорию, а сотрудникам ИБ даем возможность запускать этот файл через sudo.
4. В зависимости от ситуации, также поступаем с chcon и chcat.
5. Закрываем пользователю root возможность зайти в систему. Ограничиваем физический доступ. Оставляем su.

Все равно остается ряд проблем :) Строгая и MLS политика в этой ситуации подходит лучше, но и описанный вариант – жизнеспособен.