Месяц назад вышла девятая версия Linux-дистрибутива общего назначения Fedora. В этом посте я хотел бы продолжить разговор о системе мандатного контроля доступа SELinux и кратко рассмотреть, что же нового появилось в этой подсистеме c выходом Fedora 9. Для простоты давайте пройдемся по соответствующей секции Release Notes и разберем каждый из пунктов.
1) guest_t does not allow running setuid binaries, making network connections, or using a GUI.
Собственно, тип guest_t был добавлен еще в Fedora 8. Проведем эксперимент:
Собственно, тип guest_t был добавлен еще в Fedora 8. Проведем эксперимент:
[root@fc9 ~]# semanage login -m -s guest_u andreym
[andrey@station20 ~]$ ssh andreym@fc9
[andreym@fc9 ~]$ id
uid=501(andreym) gid=501(andreym) группы=501(andreym) context=guest_u:guest_r:guest_t:s0
Отлично. Как мы видим контекст нашего пользователя - guest_u:guest_r:guest_t:s0. Теперь попробуем отдать команды:
[andreym@fc9 ~]$ ssh localhost
ssh: connect to host localhost port 22: Permission denied
[andreym@fc9 ~]$ links http://www.markelov.net
В это время в /var/log/audit/audit.log появятся примерно такие сообщения:
type=AVC msg=audit(1213692142.442:100268): avc: denied { name_connect } for pid=27564 comm="ssh" dest=22 scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:object_r:ssh_port_t:s0 tclass=tcp_socket
и
type=AVC msg=audit(1213692261.542:100271): avc: denied { name_connect } for pid=27570 comm="links" dest=80 scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
и
type=AVC msg=audit(1213692261.542:100271): avc: denied { name_connect } for pid=27570 comm="links" dest=80 scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
No comments :)
Также помимо отсутствия взаимодействия по сети, у нас нет возможности запустить какие-либо исполнимые файлы из домашней директории, директории /tmp или любые исполнимые файлы с выставленным битом setuid. Пользователь andreym может зайти на хост fc9 c текстовой консоли, через ssh, rshd, rlogind или telnet. Однако, он не сможет использовать X-Window.
За guest_u у нас отвечает модуль:
[root@fc9 ~]# semodule -l | grep ^guest
guest 1.0.1
Для чего можно использовать такого пользователя? Например, хостинг-провайдер таким образом разрешает подключаться к web-серверу и править содержимое public_html. Или разумно задействовать guest_u, если вам необходимо предоставить доступ своим пользователям к какому-либо локальному приложению на сервере.
2) xguest_t disallows network access except for HTTP via a Web browser, and no setuid binaries.
С xguest_t мы также уже успели поэкспериментировать в Fedora 8. Dan Walsh в свое время подробно расписал использование этого типа SELinux в своем блоге http://danwalsh.livejournal.com/11913.html. Фактически, пользователь xguest идеален для создания «киоска» в общедоступном месте. Xguest может зайти локально в X-Window и запустить браузер. Никакие другие сетевые коммуникации ему не разрешены.
Если SELinux включен, то мы можем разрешить пользователю xguest вход без пароля. Для обеспечения этого был написан специальный модуль PAM - /lib/security/pam_selinux_permit.so. В свою очередь /lib/security/pam_namespace.so создает (и удаляет при выходе из системы) временные домашнюю директорию и директорию /tmp для пользователя xguest. Таким образом, между двумя сеансами работы xguest на машине ничего не сохраняется. Да, и пока мы работаем из-под xguest, никаких setuid-бинарников.
Попробовать работу с режимом «киоска» можно установив пакет:
2) xguest_t disallows network access except for HTTP via a Web browser, and no setuid binaries.
С xguest_t мы также уже успели поэкспериментировать в Fedora 8. Dan Walsh в свое время подробно расписал использование этого типа SELinux в своем блоге http://danwalsh.livejournal.com/11913.html. Фактически, пользователь xguest идеален для создания «киоска» в общедоступном месте. Xguest может зайти локально в X-Window и запустить браузер. Никакие другие сетевые коммуникации ему не разрешены.
Если SELinux включен, то мы можем разрешить пользователю xguest вход без пароля. Для обеспечения этого был написан специальный модуль PAM - /lib/security/pam_selinux_permit.so. В свою очередь /lib/security/pam_namespace.so создает (и удаляет при выходе из системы) временные домашнюю директорию и директорию /tmp для пользователя xguest. Таким образом, между двумя сеансами работы xguest на машине ничего не сохраняется. Да, и пока мы работаем из-под xguest, никаких setuid-бинарников.
Попробовать работу с режимом «киоска» можно установив пакет:
[root@fc9 ~]# yum install xguest
Соответствующая документация находится в /usr/share/doc/xguest-*
3) user_t is ideal for office users: prevents becoming root via setuid applications.
User_t — тип SELinux, предназначенный для работы непривилегированных пользователей, выполняющих обычные «офисные» задачи. В отличие от xguest, этот тип используется для «нормальных» учетных записей и взаимодействие по сети для таких пользователей не ограниченно 80 портом.
User_t — тип SELinux, предназначенный для работы непривилегированных пользователей, выполняющих обычные «офисные» задачи. В отличие от xguest, этот тип используется для «нормальных» учетных записей и взаимодействие по сети для таких пользователей не ограниченно 80 портом.
[root@fc9 ~]# semanage login -m -s user_u andreym
Безусловно, можно воспользоваться и GUI-утилитой system-config-selinux:
Также разумным вариантом можно считать использование по умолчанию user_u вместо __default__:
[root@fc9 ~]# semanage login -m -s user_u __default__
Кроме того, пользователи не могут запускать исполнимые файлы с выставленным битом setuid и обращаться к ряду системных файлов, к которым традиционно предоставляются стандартные unix-права на чтение. По умолчанию разрешено запускать исполнимые файлы из /tmp и домашней директории:
[root@fc9 ~]# getsebool allow_user_exec_content
allow_user_exec_content --> on
Установив этот переключатель в 0, вы запретите исполнение этих файлов.
4) staff_t is same as user_t, except that root access via sudo is allowed.
Staff_t - то же самое что и user_t, однако, он может работать с правами root через sudo. Не забудьте поправить файлик sudoers. Как и многие другие базовые утилиты, sudo поддерживает работу с SELinux: man sudoers.
5) unconfined_t provides full access, the same as when not using SELinux.
Этот пункт, думаю, комментировать не нужно :)
Также обратите внимание на расширенный по сравнению с Fedora 8 список модулей SELinux:
4) staff_t is same as user_t, except that root access via sudo is allowed.
Staff_t - то же самое что и user_t, однако, он может работать с правами root через sudo. Не забудьте поправить файлик sudoers. Как и многие другие базовые утилиты, sudo поддерживает работу с SELinux: man sudoers.
5) unconfined_t provides full access, the same as when not using SELinux.
Этот пункт, думаю, комментировать не нужно :)
Также обратите внимание на расширенный по сравнению с Fedora 8 список модулей SELinux:
[root@fc9 ~]# semodule -l
и включенную в Fedora среду разработки SELinux Policy IDE.
Ссылки:
1. http://docs.fedoraproject.org/release-notes/f9/en_US/sn-Security.html
2. http://www.redhatmagazine.com/2008/04/17/fedora-9-and-summit-preview-confining-the-user-with-selinux/
3. Также вы можете ознакомиться с другими статьями посвященными SELinux в моем блоге http://markelov.blogspot.com.
2. http://www.redhatmagazine.com/2008/04/17/fedora-9-and-summit-preview-confining-the-user-with-selinux/
3. Также вы можете ознакомиться с другими статьями посвященными SELinux в моем блоге http://markelov.blogspot.com.
1 комментарий:
А еще там появились какие то грабли с multicast ибо если отключить selinux то multicast работает а при включенном с default конфигурацией не работает.
Отправить комментарий