Коллеги, в первой части статьи о SElinux мы рассмотрели основные особенности работы с системой SELinux. Как и обещано, теперь публикуем вторую часть, в которой основное внимание уделено настройке политик. Что же, приступим.
Индивидуальная настройка политик SELinux
Незначительные изменения в политиках SELinux можно проводить и без полного изменения самой политики. Для этого достаточно модифицировать логические значения, связанные с дополнительными функциями, определенными в политике. Эти функции позволяют, например, предоставлять доступ к домашним каталогам пользователей при помощи Samba или позволять Apache использовать файлы, находящиеся в домашнем каталоге.
По умолчанию, эти функции отключены. Список этих функций заранее предопределен и состоит из наиболее часто используемых задач, встающих перед системным администратором.
Для того, чтобы просмотреть все доступные для вашей системы функции, достаточно выполнить следующую команду:
# getsebool -a
Для того, чтобы изменить какой-либо параметр, нужно использовать команду setsebool. Например, для того, чтобы разрешить модулям и скриптам сервиса HTTPD подключаться к сети, достаточно ввести в консоли следуещее:
# setsebool -P httpd_can_network_connect on
Создание пользовательских политик при помощи audit2allow
Иногда возникают ситуации, когда заранее предопределенных функций не хватает, когда нужно дополнить существующую политику новым модулем, вручную прописав те или иные условия предоставления доступа к чему-либо. Например, мы устанавливаем дополнение Postgrey для нашего почтового сервера, работающего по протоколу SMTP. Наш сервер должен взаимодествовать с Postgrey через Unix-сокеты, но стандартная политика SELinux для почтового сервера не позволяет этого сделать, блокирует попытки взаимодействовать через сокеты.
В подобных ситуациях не поможет изменение контекста файлов, нет дополнительных функций, включив которые, мы могли бы исправить ситуацию. Конечно, всегда можно отключить SELinux для «проблемного» сервиса, но это решение, конечно, далеко не идеально, ведь существует ненулевая вероятность того, что почтовый сервер когда-то будет взломан.
Итак, переведем SELinux в режим Permissive, после чего запустим почтовый сервер. Через некоторое время в журнале SELinux появятся AVC-сообщения, в которых будут зафиксированы все недопустимые действия нашего сервера:
type=AVC msg=audit(1218128130.653:334): avc: denied { connectto } for pid=9111 comm="smtpd" path="/var/spool/postfix/postgrey/socket"
scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1218128130.653:334): avc: denied { write } for pid=9111 comm="smtpd" name="socket" dev=sda6 ino=39977017
scontext=system_u:system_r:postfix_smtpd_t:s0 tcontext=system_u:object_r:postfix_spool_t:s0 tclass=sock_file
Теперь мы можем использовать утилиту audit2allow для того, чтобы сгенерировать набор правил для локальной политики, разрешающей все необходимые Postgrey действия:
# grep smtpd_t /var/log/audit/audit.log | audit2allow -m postgreylocal > postgreylocal.te
# cat postgreylocal.te
module postgreylocal 1.0;
require {
type postfix_smtpd_t;
type postfix_spool_t;
type initrc_t;
class sock_file write;
class unix_stream_socket connectto;
}
#============= postfix_smtpd_t ==============
allow postfix_smtpd_t initrc_t:unix_stream_socket connectto;
allow postfix_smtpd_t postfix_spool_t:sock_file write;
Итак, мы видим, что фильтруется файл audit.log, из которого вычленяются все недопустимые, с точки зрения текущей политики SELinux действия, произоводимые Postgrey. Просмотрев эти действия, мы видим, что SMTP-сервер пытается создать соединение при помощи Unix-сокета, а Postgrey пытается прослушивать этот сокет. Кажется вполне логичным взять эту информацию и создать на ее основе пользовательский модуль для политики SELinux, который разрешил бы эти действия:
# grep smtpd_t /var/log/audit/audit.log | audit2allow -M postgreylocal
Теперь мы должны загрузить этот модуль, дополнив им уже задействованные политики при помощи команды semodule:
# semodule -i postgreylocal.pp
После этого модуль перемещается в /etc/selinux/targeted/modules/active/modules/postgreylocal.pp.
Для того, чтобы проверить, корректно ли загружен модуль, можно вывести список всех загруженных модулей при помощи команды «semodule -l».
После этого мы можем продолжить наблюдение за журналом SELinux, чтобы убедиться в том, что наша только что созданная политика не ограничивает Postgrey. Как только мы будем довольны и уверены в правильной работе политики, мы можем снова активировать режим Enforcing, в полной уверенности, что теперь наш почтовый сервер надежно защищен и, в то же время, полноценно функционирует.
Ручная настройка модулей для политик SELinux.
Adit2allow, без сомнения, отлично справляется с созданием моделей для политик, которые решают какую-то конкретную проблему. Но иногда и эта утилита срабатывает не совсем верно, так что приходится настраивать модуль вручную. Например, рассмотрим записи в журнале AVC-журнале SELinux:
Summary:
SELinux is preventing postdrop (postfix_postdrop_t) "getattr" to
/var/log/httpd/error_log (httpd_log_t).
Detailed Description:
SELinux denied access requested by postdrop. It is not expected that this access
is required by postdrop and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.
Allowing Access:
Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for /var/log/httpd/error_log,
restorecon -v '/var/log/httpd/error_log'
If this does not work, there is currently no automatic way to allow this access.
Instead, you can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.
Additional Information:
Source Context system_u:system_r:postfix_postdrop_t
Target Context root:object_r:httpd_log_t
Target Objects /var/log/httpd/error_log [ file ]
Source postdrop
Source Path /usr/sbin/postdrop
Port <Unknown>
Host sanitized
Source RPM Packages postfix-2.3.3-2
Target RPM Packages
Policy RPM selinux-policy-2.4.6-137.1.el5
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name catchall_file
Host Name sanitized
Platform Linux sanitized 2.6.18-53.1.21.el5 #1 SMP Tue
May 20 09:35:07 EDT 2008 x86_64 x86_64
Alert Count 599
First Seen Wed Jul 2 08:27:15 2008
Last Seen Sun Aug 10 22:47:52 2008
Local ID c303a4ea-8e7a-4acc-9118-9cc61c6a2ec8
Line Numbers
Raw Audit Messages
host=sanitized type=AVC msg=audit(1218397672.372:352): avc: denied { getattr } for pid=4262 comm="postdrop"
path="/var/log/httpd/error_log" dev=md2 ino=117005 scontext=system_u:system_r:postfix_postdrop_t:s0
tcontext=root:object_r:httpd_log_t:s0 tclass=file
host=sanitized type=SYSCALL msg=audit(1218397672.372:352): arch=c000003e syscall=5 success=no exit=-13 a0=2
a1=7fffd6febca0 a2=7fffd6febca0 a3=0 items=0 ppid=4261 pid=4262 auid=4294967295 uid=48 gid=48 euid=48 suid=48
fsuid=48 egid=90 sgid=90 fsgid=90 tty=(none) comm="postdrop" exe="/usr/sbin/postdrop"
subj=system_u:system_r:postfix_postdrop_t:s0 key=(null)
После того, как мы запустим audit2allow и рассмотрим получившуюся в результате политику postfixlocal.te, мы увидим следующее:
# grep postdrop /var/log/audit/audit.log | audit2allow -M postfixlocal
# cat postfixlocal.te
module postfixlocal 1.0;
require {
type httpd_log_t;
type postfix_postdrop_t;
class dir getattr;
class file { read getattr };
}
#============= postfix_postdrop_t ==============
allow postfix_postdrop_t httpd_log_t:file getattr;
Сразу же возникает вопрос, зачем PostDrop пытается получить доступ к /var/log/httpd/error_log? Это не то действие, которое мы могли бы ожидать от этой программы, так что теперь только нам решать позволять это действие или нет.
У нас есть несколько путей решения этой проблемы.
— Мы можем игнорировать эту ошибку и позволить SELinux блокировать доступ к файлу.
— Мы можем позволить это действие, создав соответствующий модуль политики при помощи audit2allow.
— Мы можем вручную отредактировать файл этого модуля, чтобы определить нужную нам реакцию SELinux на попытку доступа к файлу. Например, мы можем запретить аудит этого события, блокирую в тоже время доступ. Для этого мы должны изменить значение «allow» в соответствующей строке на «dontaudit»:
#============= postfix_postdrop_t ==============
dontaudit postfix_postdrop_t httpd_log_t:file getattr;
Теперь мы должны вручную скомпилировать и загрузить отредактированный модуль политики:
# checkmodule -M -m -o postfixlocal.mod postfixlocal.te
# semodule_package -o postfixlocal.pp -m postfixlocal.mod
# semodule -i postfixlocal.pp
Таким образом доступ к файлу /var/log/httpd/error_log блокируется, но мы не получаем постоянных предупреждений об этом от SELinux.
Собственно, по SELinux пока все, а в последующих статьях мы рассмотрим такую интересную (и, надеемся, полезную) тему, как дисковые квоты в linux для rpm-дистрибутивов. Новая статья будет опубликована уже в понедельник.
Автор: itNews
