 |
Политика для созданного демона
|
|
|
|
По умолчанию, в целевой политике все процессы, для которых не определены собственные политики, запускаются в домене unconfined_t, в котором SELinux разрешает все.
На специальном языке программирования создадим собственную политику безопасности, разрешающую демону записывать сообщения в файл лога, который будет находиться в домашнем каталоге сущности hevil (в моем случаем это будет /home/hevil).
Для этого придется отредактировать несколько файлов, ну а потом скомпилировать и загрузить политику вышеуказанными способами.
Для начала нужно создать саму сущность hevil. Прошу заметить, что в настоящий момент мы находимся от имени пользователя root системы UNIX, но в SELinux это будет сущность (пользователь) hevil.
В конец файла /ets/selinux/targeted/policy/src/users.te нужно добавить следующее объявление:
user hevil roles { user_r hevil_r };
Данная строчка означает, что будет создан пользователь hevil с ролями user_r и hevil_r.
Чтобы можно было запустить демона под данной сущностью нужно прописать роль hevil_r в /ets/selinux/targeted/policy/src/domains/misc/hevil.te:
full_user_role(hevil); # Создание обычной пользовательской роли (назначение
# соответствующих прав)
in_user_role(hevil_daemon_t); # Объявление перехода контекста роли user_r в домен
# hevil_daemon_t
Добавим правило перехода между ролями в /ets/selinux/targeted/policy/src/rbac:
allow user_r hevil_r;
allow hevil_r user_r;
Теперь можно будет свободно переходить из роли user_r в hevil_r.
Определим макрос перехода контекста, для этого нужно отредактировать файл
/ets/selinux/targeted/policy/src/ /macros/user_macros.te, добавив следующие строки:
undefine(`in_user_role')
define(`in_user_role', `
role user_r types $1;
role staff_r types $1;
role hevil_r types $1;')
Устанавливаем с командной строки контекст для домашнего каталога /home/hevil:
find /home/hevil -print0|xargs -0 chcon --h hevil:object_r:hevil_home_t
chcon -h hevil:object_r:hevil_home_dir_t /home/hevil
|
|
|
Типы hevil_home_dir_t и hevil_home_t автоматически создались при создании сущности.
Для корректной работы политики необходимо создать еще тип директории с демоном, тип файла с демоном и исполняемого файла. Это достигается редактированием файла /ets/selinux/targeted/policy/src//types/hevil_types.te:
# Создание соответствующих типов
type hevil_daemon_t, domain;
type hevil_daemon_dir_t, dir_type;
type myapp_exec_t, file_type, sysadmfile, exec_type;
# Правило перехода от типа hevil_daemon_t
# к hevil_daemon_exec_t
type_transition hevil_daemon_t hevil_daemon_exec_t:{ file }
Далее установим контекст для этой директории и файла. Эти действия аналогичны, как и для домашнего каталога.
find /root/daemon -print0|xargs -0 chcon --h hevil:object_r:hevil_home_t
chcon -h hevil:object_r:hevil_home_dir_t /root/daemon
Устанавливаем правило доступа hevil_r к hevil_daemon_t и hevil_daemon_dir_t.
hevil_t - это пользовательский домен роли hevil_r (создается автоматически).
hevil_daemon_exec_t - тип исполняемого файла.
# Разрешение записи в директорию с демоном
rw_dir_create_file(hevil_t, hevil_daemon_dir_t)
# Разрешение запуска демона
can_exec(hevil_t, hevil_daemon_exec_t)
Создаем домен, в котором выполняется демон. В файл /ets/selinux/targeted/policy/src/domains/program/hevil.te вписываем строчку:
daemon_domain(daemon_t);
Данный макрос создаст стандартный домен для демона.
В этот же файл добавим еще правило для демона:
role system_r types daemon_t; #разрешен доступ суперпользователя
role hevil types daemon_t; #разрешен доступ для hevil
in_iser_role(daemon_t) #объявление перехода контекста hevil в #daemon_t
# Автоматически при запуске демона осуществляется переход
# в домен демона
domain_auto_trans(hevil_t, hevil_daemon_exec_t, daemon_t)
# Разрешаем init переходить в daemon_t при загрузке
domain_auto_trans(initrc_t, daemon_exec_t, daemon_t)
#hevil_t может перейти в daemon_t во время запуска демона
domain_auto_trans(hevil_t, daemon_exec_t, daemon_t)
#доступ к терминалу
allow daemon_t admin_tty_type:chr_file rw_file_perms;
#разрешение на запись в файл
allow daemon_t { ttyfile ptyfile }:chr_file rw_file_perms;
#разрешение писать в файл домашнего каталога
rw_dir_create_file(daemon_t, hevil_home_dir_t)
Теперь остается самый ответственный этап: компилирование и загрузка политики в память. make load
|
|
|
Демонстрация работы демона
Суперпользователь имеет максимальные права в системе, поэтому все процессы, запущенные от его имени будут иметь такой же уровень привилегий.
Регистрируемся в системе под root.
Запускаем демона командой./hevil (в каталоге с программой).
Получается, что демон, запущенный пользователем root, будет имеет максимальные, ничем не ограниченные права.
С помощью команды kill [номер сигнала] [PID процесса] посылаем различные сигналы демону. Просмотрев журнал можно убедиться, что все записано в лог, т.е. демон работоспособен.
Теперь с помощью команды make load загружаем новую политику в память.
Теперь посылаем сигналы демону. Он выдаст сообщение об ошибки, что невозможно записать в файл. Это объясняется тем, что правила политики, запрещают производить запись в заданный файл, в то время как классическая система безопасности это разрешает.
Для проверки можно зайти в каталог с логом непосредственно пользователем root и убедиться, что доступ для самого пользователя в заданный каталог разрешен.
Заключение
В данной работе была освещен Security-Enhanced Linux — линукс с улучшенной безопасностью.
Достоинства данной технологии очевидны, т.к. он базируется на принципе наименьших прав, т.е. запущенному процессу дается именно столько прав, сколько ему требуется. Более того, SELinux существует параллельно с классической системой безопасности Linux, независим от нее. SELinux обрабатывает только те запросы, которые разрешены классической системой безопасности и не может разрешить то, что запрещено последней. На примере демона, запущенного от имени root (т.е. с нулевым уровнем привилегий) было продемонстрирована «сила» Security-Enhanced Linux.
Недостатком SELinux является то, что отсутствует удобное ПО по разработке своей собственной политики. Вариант редактирования исходных кодов политик, компилирования, просмотра логов и внесение изменений в код, двигаясь пошагово в цикле – является неудовлетворительным.
В настоящее время ведутся активные работы как по переводу документации SELinux на русский язык, так и попыток создания ПО.
Несомненно, нужно отметить, что LUG (Linux User Group) нашего университета тоже присоединилось к этому движению. Несколько студентов решили объединить свои силы для помощи мировому сообществу.
|
|
|
Ознакомиться с задачами, которые были поставлены в LUG можно на сайте http://www.selinux.ru.
Список литературы
1. Эви Немеет, Гарт Снайдер, Скотт Сибасс, Трент Р.Хейн «UNIX. Руководство системного администратора для профессионалов», 3-е издание
2. Марк Дж. Рочкинд «Программирование для UNIX. Наиболее полное руководство в подлиннике», 2-е издание
3. Алексей Стахнов «Linux. Наиболее полное руководство в подлиннике», 2-е издание
4. http://www.redhat.ru/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/index.html - официальное руководство по SELinux для Red Hat 4 [03.06.2006].
5. http://www.nsa.gov/selinux - Официальный сайт NSA [03.06.2006].
6. http://www.nsa.gov/selinux/faq.html - Официальный документ SE Linux FAQ [03.06.2006].
7. http://www.nsa.gov/selinux/docs.html - Опубликованные NSA материалы, отчёты и презентации. [03.06.2006].
8. http://www.rhd.ru/docs/articles/selinux_rhel4/ - Получите преимущества SELinux в Red Hat® Enterprise Linux® 4. Фай Кокер и Рассел Кокер. [03.06.2006].
9. http://gazette.lrn.ru/rus/articles/intro_selinux.html - Введение в SE Linux: новый SE Linux. Фей Кокер. [03.06.2006].
10.http://ru.wikipedia.org/wiki/SELinux - Материал из Википедии
11.http://www.osp.ru/text/302/185543/ - SELinux — система повышенной безопасности. Андрей Боровский. [03.06.2006].
Приложение 1
|
|
|
