Разберемся, что такое MCS и как ограничить пользователям (в том числе и администратору) доступ к информации при помощи категорий SELinux. Продолжаем разговор, начатый постами:
Часть 1. SELinux. Максимальный уровень защиты – бесплатно.Часть 2.1. 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 -l
Level 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.
6. Все равно остается ряд проблем :) Строгая и MLS политика в этой ситуации подходит лучше, но и описанный вариант – жизнеспособен.
В следующем посте я постараюсь сделать небольшой обзор всех доступных в интернет и в off-line источников информации посвященных SELinux. К сожалению, в основном все на английском языке. Русскоязычных статей и переводов явный недостаток.
