Использование SELinux совместно с iptables

Dan Walsh, отвечающий в Red Hat за развитие SELinux опубликовал на Linux.com статью, посвященную использованию SELinux совместно с брандмауэром. Ссылка.

Развитие проекта sVirt в Fedora 11/RHEL

Я уже рассказывал в своем блоге о проекте sVirt, позволяющем изолировать при помощи мандатного контроля доступа гипервизор и отдельные виртуальные машины друг от друга. Если вы еще не знакомы с концепцией MAC, MLS и MSC, то вы можете почитать соответствующие записи в моем блоге с меткой SELinux. Не буду повторяться, а просто скажу, что уникальные преимущества в плане защищенности, доступные в операционных системах общего назначения с открытым исходным кодом уже можно живьем "пощупать" и в системах виртуализации (Fedora 11), а с выходом RHEL 5.4 и внедрить на предприятии.

В изначально реализованной политике для RHEL5, xend_t - домен в котором работает процесс Xen, не мог обойтись без права писать/читать не только в файлы xen_image_t, но и в физические устройства fixed_disk_device_t, поскольку в промышленной среде использование образов дисков вместо отдельных разделов, например на LVM, имеет ряд недостатков. Таким образом, злоумышленник из процесса xend_t в случае компрометации одной из виртуальных машин в принципе мог бы получить доступ как к самому хосту, так и к другим виртуальным машинам.

Данная проблема в целом распространяется и на другие системы виртуализации - от Microsoft, VMware и других вендоров. От "zero-day" уязвимости в ОС виртуальной машины и гипервизора одновременно не застрахован никто. Однако в случае Fedora (и в будующем RHEL) решениеп такой проблемы теперь есть. Одной частью решения в Fedora 11 стал появившийся в libvirt механизм подключаемых модулей. Теперь специальный plug-in динамически присваивает метки файлам\устройствам "на лету" и стартует виртуальные машины в соответствующем домене SELinux. По умолчанию в Fedora процессы виртуальных машин работают в доменах svirt_t, а фалы/устройства имеют тип svirt_image_t.

Описанное выше позволит защитить только операционную систему хоста (гипервизор) от атаки осуществляемой изнутри скомпрометированной виртуальной машины. Для изоляции же виртуальных машин друг от друга разработчики используют поддержку мультикатигорийной безопасности (подмножество реализации многоуровневой безопасности с одним и тем-же уровнем безопасности s0). За подробностями опять-же отправляю к предыдущим постам в блоге. Соответствующие друг-другу контексты и домены виртуальных машин с совпадающими категориями (как я уже сказал уровень безопасности при этом используется один и тот же) присваиваются libvirt случайным образом. Однако, при необходимости, администратор может задать их и статически. Подробнее почитать про sVirt можно в блоге Дэна Уолша, отвечающего в Red Hat за разработку SELinux.

sVirt = Виртуализация + Мандатный контроль доступа

Продолжу рассказ про перспективные разработки в области виртуализации. Давайте рассмотрим отдельно стоящий сервер, к которому в силу тех или иных причин злоумышленник получил доступ с привилегиями администратора. Плохо? Безусловно. Теперь у злоумышленника "ключи" от всех выполняющихся на сервере служб. А теперь представьте, что в роли сервера у нас машина с гипервизором, в котором работает какое-то количество виртуальных машин. Ситуация хуже во много раз: "плохие парни" получают доступ сразу ко всем виртуальным машинам. Тем более, что опасность увеличивается, благодаря использованию в случае гостевых операционных систем локальных механизмов атаки. Оставим в стороне конкретные технологии и конкретных вендоров. Не важно, чья модель безопаснее - Microsoft, VMWare, Citrix, Sun, etc. Никто не будет спорить, что от потенциальных уязвимостей не застрахован никто, вне зависимости от размеров возможной площади атаки.

Теперь снова вернемся к более простому и традиционному случаю - получению привилегий на отдельно стоящем сервере/ОС. Данная проблема более традиционна, и для ее решения уже существуют технологии. Благодаря таким решениям, ряд операционных систем общего назначения, например, уже получило высокий уровень сертификации Common Сriteria EAL4+ (c расширениями LSPP, RBACPP и CAPP).

Такие "заклинания", как мандатный контроль доступа (MAC), многоуровневая система безопасности (MLS), мульти-категорийная безопасность (MCS) уже не раз встречались в моем блоге в контексте операционной системы. Я не буду повторяться, и просто дам ссылку на посты с тегом "SELinux", где я и писал про практическую реализацию ограничений привилегий системного администратора :) Итак, идея состоит в том, чтобы защитить гипервизор при помощи существующих решений мандатного контроля доступа.

Теперь вернемся к конкретике :) Проект sVirt, направленный на решение этой задачи, был анонсирован Джеймсом Моррисом в рассылке libvirt в августе прошлого года. Цель проекта - интеграция SELinux и виртуализации на основе Linux-ориентированных технологий. Недостаточность традиционного дискреционного контроля доступа в системах, требующих особой защищенности, обуславливается тем, что субъект может менять собственную политику безопасности. С другой стороны, если гостевые операционные системы будут изолированы при помощи политик мандатного контроля доступа, то это резко снижает возможный ущерб от успешной атаки, а то и вовсе ее предотвращает. В идеале в каждом процессе виртуальная машина должна работать в собственном контексте безопасности. Снова в качестве иллюстрации посмотрим на отдельную - не виртуализированную - операционную систему. Вы без труда найдете примеры, когда реальные уязвимости, затрагивающие ОС, в том или ином компоненте операционной системы с отключенным SELinux успешно блокировались политикой безопасности при включенном мандатном контроле.

К своей первой версии sVirt должен обеспечивать реализацию MAC на уровне ядра гипервизора, и обеспечивать простую изоляцию виртуальных машин, не требуя никакой настройки, т.е. все должно работать "из коробки". Ресурсы каждой гостевой операционной системы должны иметь свой уникальный контекст virtd_isolated_t:. Взаимодействие между доменами при этом исключается. В будущем планируется выделить разные типы гостевых машин, требующих разную политику, например, virtd_isolated_webserver_t, реализовать политику SELinux на уровне сетевого взаимодействия, многоуровневую систему безопасности (MLS).

В каком состоянии находится проект сейчас? Сделана низкоуровневая интеграция с libvirt, базовая поддержка в virsh, и виртуальные машины могут запускаться в своих контекстах безопасности. Как и в случае с oVirt, в первую очередь работа идет над KVM.

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

Fedora Linux Security Guide

Руководство Security-Enhanced Linux User Guide, про которое я писал ранее, уже сменило статус с черновика на готовый документ, а вчера Eric Christensen опубликовал черновой вариант Fedora Linux Security Guide (Bugzilla Bug). В целом завершить работу планируется к выходу Fedora 11, а сейчас создатели документа с удовольствием выслушают отклики/исправления/замечания от сообщества пользователей и разработчиков Fedora. HTML-версия документа тут.

Настраиваем TLS/SASL-шифрование и аутентификацию в MTA Sendmail

При помощи механизма STARTTLS и сертификатов мы попробуем настроить взаимную аутентификацию и шифрование пересылаемой почты между двумя почтовыми серверами с MTA Sendmail. Также при помощи TLS защитим отправляемую клиентами на сервер почту и настроим почтовый релей для пересылки корреспонденции только тех пользователей, которые предъявят сертификат, выданный нашим центром сертификации (CA).

STARTTLS (RFC 2487) является расширением протокола SMTP. STARTTLS в первую очередь предназначен для поддержки TLS-шифрования и аутентификации между двумя почтовыми серверами. Но как вы увидите далее, он с успехом может применяться и почтовыми клиентами.

MTA Sendmail в нашей тестовой конфигурации будет работать на двух серверах Red Hat Enterprise Linux 5.1. Выбор не является принципиальным – вы можете использовать ваш любимый или вовсе установить Sendmail в другой операционной системе, например Solaris. Единственное, с чем вы можете столкнуться, – отличие поставляемого по умолчанию в вашем дистрибутиве конфигурационного файла sendmail.mc от использующегося в Red Hat Enterprise Linux/Fedora.

Также предполагаем, что у нас есть настроенный центр сертификации. Для простоты будем использовать OpenSSL, но, естественно, это непринципиально. Один из наших тестовых серверов прекрасно справится с этой ролью. Конечно, в реальной работе вы не должны разворачивать CA и публичный почтовый сервер на одной машине.

В качестве «компенсации» засилья Open Source-инструментов в роли MUA используем штатную в Windows Vista программу Windows Mail.

Базовые настройки и взаимодействие двух почтовых серверов

Начнем с сертификата для MTA. Необходимо отметить, что STARTTLS в данном случае защищает только трафик между двумя соответствующим образом настроенными почтовыми серверами. Нет никакой гарантии при отправке письма «во вне», что все релеи, через которые пройдет письмо, используют STARTTLS. Никогда не надо забывать, что отправка письма через Интернет аналогична отправке почтовой карточки по обыкновенной почте. Текст вашего письма может быть прочитан во всех точках, через которые пересылается письмо. Для гарантированной защиты электронной почты между отправителем и получателем необходимо использовать шифрование при помощи S/MIME или GnuPG/PGP.

Генерируем для нашего сервера приватный ключ и создаем запрос в центр сертификации:

# openssl genrsa 1024 > sendmail.key
# openssl req -new -key sendmail.key -out sendmail.csr

После чего необходимо переслать запрос на выдачу сертификата в центр сертификации. Администратор центра сертификации выпускает на основе запроса сертификат:

# openssl ca -in sendmail.csr -out sendmail.crt

Копируем полученный сертификат на почтовый сервер и кладем рядом с ключом в директорию /etc/pki/tls/certs. Права на оба файла должны быть выставлены 600 или 400.

Далее начинаем править конфигурационный файл /etc/mail/sendmail.mc. Редактируем пути и убираем комментарии со строк:

# Директория с сертификатами
define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl
# Сертификат CA, выдавшего сертификат нашему серверу.
# Не забудьте его также скопировать в указанную директорию
define(`confCACERT', `/etc/pki/CA/cacert.pem')dnl
# Сертификат нашего сервера, используемый во время
# приема почты
define(`confSERVER_CERT', `/etc/pki/tls/certs/sendmail.crt')dnl
# Приватный ключ нашего сервера
define(`confSERVER_KEY', `/etc/pki/tls/certs/sendmail.key')dnl

и добавляем две новых строки:

# Сертификат и приватный ключ нашего сервера, используемый для отправления почты на другой сервер.
# Для простоты используем те же, файлы, что и в первом случае
define(`confSERVER_CERT', `/etc/pki/tls/certs/sendmail.crt')dnl
define(`confSERVER_KEY', `/etc/pki/tls/certs/sendmail.key')dnl

Для проверки наших настроек зайдем на 25-й порт сервера при помощи команды telnet:

# openssl ca -in sendmail.csr -out sendmail.crt

Trying 192.168.0.17...

Connected to station17.example.com (192.168.0.17).

Escape character is '^]'.
220 station17.example.com ESMTP Sendmail 8.13.8/8.13.8; Thu, 31 Jul 2008 14:21:33 +0400
EHLO station18.example.com
250-station17.example.com Hello station18.example.com [192.168.0.18], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP
STARTTLS
220 2.0.0 Ready to start TLS
QUIT

Повторяем те же действия по настройке (включая выпуск второго сертификата) для второго сервера. В нашей ситуации оба сервера используют один и тот же удостоверяющий центр. Если используются разные CA, то MTA будут необходимы корневые сертификаты обоих.

Теперь если мы попробуем на одном из серверов локально запустить MUA, например mutt, и отправить сообщение пользователю второго сервера, то на первом сервере в /var/log/maillog увидим примерно такие сообщения:

Jul 31 01:07:21 station18 sendmail[9558]: STARTTLS=client, relay=station17.example.com.,
version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul 31 01:07:21 station18 sendmail[9558]: m6UL7Lpc009556: to=,
ctladdr= (0/0), delay=00:00:00, xdelay=00:00:00, mailer=esmtp,
pri=120467, relay=station17.example.com. [192.168.0.17], dsn=2.0.0, stat=Sent (m6UL7LpK009193
Message accepted for delivery)

А на принимающем соответственно:

Jul 31 01:07:21 station17 sendmail[9193]: STARTTLS=server, relay=station18.example.com [192.168.0.18],
version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul 31 01:07:21 station17 sendmail[9193]: m6UL7LpK009193: from=, size=748,
class=0, nrcpts=1, msgid=<20080730210721.ga9548@station18.example.com>, proto=ESMTP, daemon=MTA,
relay=station18.example.com [192.168.0.18]
Jul 31 01:07:21 station17 sendmail[9194]: m6UL7LpK009193: to=,
delay=00:00:00, xdelay=00:00:00, mailer=local, pri=31037, dsn=2.0.0, stat=Sent

Как видно из журнала, серверы аутентифицировали друг друга при помощи сертификатов, выданных одним и тем же CA, и при пересылке письма информация была зашифрована. Данный факт можно проверить, запустив на одном из тестовых серверов утилиту wireshark или tcpdump.

Настройка TLS для клиента

В текущем состоянии Sendmail готов работать с клиентом, принимая от него почту в зашифрованном виде, однако никакой проверки клиента при помощи механизма TLS не используется. Зато клиенту не нужны сертификаты, и всего лишь достаточно поставить соответствующую галку – «использовать защищенное соединение, TLS».

В журнале почтового сервера это выглядит примерно так:

Jul 30 23:29:09 station17 sendmail[8228]: STARTTLS=server, relay=station51.example.com [192.168.0.51],
version=TLSv1/SSLv3, verify=NO, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul 30 23:29:09 station17 sendmail[8228]: m6UJT8GH008228: from=, size=341,
class=0, nrcpts=1, msgid=<4890c39d.4020404@station17.example.com>, proto=ESMTP, daemon=MTA,
relay=station51.example.com [192.168.0.51]
Jul 30 23:29:09 station17 sendmail[8229]: m6UJT8GH008228: to=,
ctladdr= (507/508), delay=00:00:00, xdelay=00:00:00, mailer=local,
pri=30623, dsn=2.0.0, stat=Sent

Как видно, напротив verify мы видим значение «NO». Попробуем «закрутить гайки».

Сгенерируем сертификат для пользователя. Раз мы начали работать с OpenSSL, для упрощения задачи предположим, что наш пользователь также воспользуется этой утилитой. Естественно, какими средствами будет сгенерирован запрос в центр сертификации, нам не важно. В «боевой» среде скорее всего пользователь воспользуется каким-либо веб-интерфейсом.

Итак, от лица пользователя:

# openssl genrsa 1024 > andrey.key
# openssl req -new -key andrey.key -out andrey.csr

И от лица администратора CA:

# openssl ca -in andrey.csr -out andrey.crt

Далее необходимо «упаковать» ключ и сертификат в формат PKCS#12:

# cat andrey.key andrey.crt > andrey.pem
# openssl pkcs12 -export -in andrey.pem -out testusercert.p12 -name "Andrey's Personal cert"

«Скармливаем» персональный сертификат и сертификат CA выбранному MUA, в нашем случае программе Windows Mail.

А на сервере остается прописать, кому разрешена пересылка почты через наш сервер:

# cat /etc/mail/access
Connect:localhost.localdomain RELAY
Connect:localhost RELAY
Connect:127.0.0.1 RELAY
CERTISSUER:/C=GB/ST=Berkshire/L=Newbury/O=My+20Company+20Ltd/CN=Station+2018+20CA RELAY
CERTSUBJECT:/C=GB/ST=Berkshire/L=Newbury/O=My+20Company+20Ltd/CN=Station+2018+20CA RELAY

В данном случае мы разрешаем пересылку только обладателям сертификатов, выданных нашим CA.

Параметры CERTISSUER и CERTSUBJECT мы заполняем значениями, взятыми из полей Issuer и Subject сертификата CA:

# openssl x509 -in cacert.pem -noout -subject -issuer
subject= /C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd/CN=Station 18 CA
issuer= /C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd/CN=Station 18 CA

При этом ряд символов, в том числе «{», «<», «>», «(», «)», «"», «+», «}», и пробел заменяются на шестнадцатеричные ASCII-коды, предваряемые символом «плюс». Соответствующие коды можно посмотреть в странице руководства:

# man ascii

Успешная попытка обладателя сертификата использовать наш почтовый сервер в качестве релея в журнале /var/log/messages будет выглядеть примерно следующим образом:

Jul 31 02:10:31 station17 sendmail[9700]: STARTTLS=server, relay=station51.example.com [192.168.0.51],
version=TLSv1/SSLv3, verify=OK, cipher=AES128-SHA, bits=128/128
Jul 31 02:10:31 station17 sendmail[9700]: m6UMAVTH009700: from=, size=1128,
class=0, nrcpts=1, msgid=<57a621a4bfcb411f9acde6a1d9ce3e62@andreypc>, proto=ESMTP, daemon=MTA,
relay=station51.example.com [192.168.0.51]
Jul 31 02:10:31 station17 sendmail[9702]: STARTTLS=client, relay=station18.example.com.,
version=TLSv1/SSLv3, verify=OK, cipher=DHE-RSA-AES256-SHA, bits=256/256
Jul 31 02:10:31 station17 sendmail[9702]: m6UMAVTH009700: to=,
ctladdr= (507/508), delay=00:00:00, xdelay=00:00:00, mailer=esmtp,
pri=121128, relay=station18.example.com. [192.168.0.18], dsn=2.0.0, stat=Sent (m6UMAVR4009739 Message
accepted for delivery)

Если вы увидели подобные сообщения в журнале, значит наша цель достигнута. Убедиться в том, что соответствующий сеанс защищен, вы можете при помощи утилиты wireshark.
Таким образом, как видите, при всей относительной сложности настройки MTA Sendmail, механизм STARTTLS включается достаточно просто.

Андрей Маркелов

Впервые опубликовано в журнале "Системный администратор", август 2008

Переход на новые репозитории и ключи для Fedora 8 и Fedora 9

После инциндента с компроментацией инфраструктурных серверов Fedora, были заменены ключи, используемые для подписи пакетов, и изменено месторасположение репозиториев с обновлениями. Процедура перехода на новые репозитории максимально упрощена.

Сегодня для систем, работающих со старыми репозиториями, стали доступны обновления:

[root@f9-server ~]# yum check-update
Loaded plugins: presto, refresh-packagekit
PackageKit.i386

0.2.5-1.fc9 updates
PackageKit-libs.i386 0.2.5-1.fc9 updates
fedora-release.noarch 9-5.transition updates
gnome-packagekit.i386 0.2.5-2.fc9 updates
yum-packagekit.i386 0.2.5-1.fc9 updates

После установки пакетов утилиты yum, PackageKit и pirut будут видеть новые репозитории и достаточно большое число обновленных пакетов:

Вам потребуется подтвердить, что вы доверяете новому ключу:

Подробнее тут.

Статья "Настройка TLS/SASL-шифрования и аутентификации в MTA Sendmail"

В августовском номере журнала «Системный администратор» опубликована моя статья "Настройка TLS/SASL-шифрования и аутентификации в MTA Sendmail".

"При помощи механизма STARTTLS и сертификатов мы попробуем настроить взаимную аутентификацию и шифрование пересылаемой почты между двумя почтовыми серверами с MTA Sendmail. Также при помощи TLS защитим отправляемую клиентами на сервер почту и настроим почтовый релей для пересылки корреспонденции только тех пользователей, которые предъявят сертификат, выданный нашим центром сертификации (CA).

STARTTLS (RFC 2487) является расширением протокола SMTP. И в первую очередь предназначен для поддержки TLS-шифрования и аутентификации между двумя почтовыми серверами. Но как мы увидим далее он с успехом может применяться и почтовыми клиентами."

Спустя два месяца с разрешения редакции статья будет размещена на моем сайте.

Sectool — утилита аудита безопасности систем основанных на Fedora/RHEL

sectool — активно развивающийся инструмент аудита настроек безопасности и локальная IDS для дистрибутивов, основанных на Fedora. Включает в себя ряд тестов для различных аспектов настройки системы, служб и т.д. В настоящий момент их около тридцати. Тесты независимы от языка программирования (Perl, Python, Bash, ...) и их можно писать самостоятельно (на сайте проекта доступна документация).

Имеется как графический, так и интерфейс командной строки. В графике проверка сводится к выбору настраиваемого класса тестов (Базовый, Рабочая станция, Сеть, Сервер, «Параноик») и нажатию кнопки запуска анализа системы. Естественно имеется гибкая система настроек, сравнение результатов проверок, отправка отчетов по электронной почте и т.д.

Установка:

[root@fedora9 ~]# yum install # yum install sectool sectool-gui

Запуск графического интерфейса:

[root@fedora9 ~]# sectool-gui

Сайт проекта:

https://fedorahosted.org/sectool

Kerberized NFSv4 issue in RHEL 5.1

При настройке NFSv4 в связке с Kerberos на сервере с Red Hat Enterprise Linux 5.1 столкнулся с тем, что в Kerberos был изменен алгоритм по умолчанию с des-cbc-crc на 3des-cbc-hmac. Это конечно здорово, но вот NFSv4 работает только с алгоритмом шифрования des-cbc-crc.
Соответственно, когда добавляем созданного принципала nfs/stationX.example.com в /etc/krb5.keytab нужно в ktadd указать алгоритм:

kadmin: ktadd -e des-cbc-crc:normal -k /etc/krb5.keytab \
nfs/stationX.example.com

В противном случае получаем в /var/log/messages ошибку:

gss_kerberos_mech: unsupported algorithm 7

Новая статья в Red Hat Magazine посвященная SELinux

В Red Hat Magazine вышла новая статья "Writing policy for confined SELinuxusers ", написанная Dan Walsh. В ней Dan на примере двух простых задач описывает как при помощи мастера создания модулей политики
в утилите system-config-selinux можно модифицировать существующий тип пользователя и как добавить новый.

В первом примере модифицируется политика для xguest, позволяя этому пользователю не только запускать браузер, но и работать с IM по протоколу
AIM/AOL. Во втором примере создается новый тип пользователя, которому разрешено пользоваться терминалом, отправлять почту и читать/писать
в /maildir.

Отличная статья для первоначального знакомства с некоторыми расширенными в Fedora 9 функциями GUI-утилиты system-config-selinux.

Red Hat Enterprise IPA

Сегодня компания Red Hat анонсировала новый продукт под названием Red Hat Enterprise IPA, являющийся решением с открытым исходным кодом для управления доступом и учетными данными. Red Hat Enterprise IPA осуществляет централизованную аутентификацию, управление политиками доступа и аудита для компьютеров, пользователей и сервисов в Unix и Linux-окружениях. В состав решения входят ряд служб, в том числе: LDAP, Kerberos и RADIUS. Помимо этого существуют средства для интеграции с другими сервисами каталогов, включая Active Directory и утилиты для миграции с NIS. Для упрощения работы с Red Hat Enterprise IPA в состав решения входит консоль управления с web-интерфейсом.

Важным преимуществом решения является то, что оно основывается на полностью открытых стандартах и технологиях, что является отличной защитой инвестиций и позволяет избежать замыкания на продуктах конкретного вендора (vendor lock-in).

Основные особенности решения:

• SSO при помощи единой учетной записи, используя Kerberos и LDAP (Red Hat Directory Server) для доступа к компьютерам и службам
• Возможность использовать нескольких полностью равноправных мастер-серверов с автоматическим разрешением конфликтов
• Синхронизация с уже существующими серверами каталогов, включая Active Directory. В следующих версиях помимо односторонней или двухсторонней синхронизации планируется возможность использовать выданные Active Directory билеты Kerberos в Kerberos-области Red Hat Enterprise IPA, а также интеграция с Red Hat Certificate System
• Использование открытых стандартов
• Простота установки и управления законченным решением
• Расширение функционала за счет подключаемых модулей (plug-ins)

Функциональная схема первой версии Red Hat Enterprise IPA/Free IPA:

Требования к серверу:

• Red Hat Enterprise Linux 5 (32 или 64-bit)

Требования к клиентам:

• Red Hat Enterprise Linux версий 2.1, 3, 4, 5
• HP-UX версий 11, 11i v.1 и 2
• Sun Solaris 2.6, 7, 8, 9, 10
• AIX 5.1, 5.2, 5.3
• Mac OS X
• Microsoft Windows XP/2000
  

В качестве основы Red Hat Enterprise IPA выступает спонсируемый компанией Red Hat проект FreeIPA. Фактически Red Hat Enterprise IPA - это FreeIPA с поддержкой от Red Hat.

Пара снимков с экрана web-интерфейса тестового сервера FreeIPA. Red Hat Enterprise IPA должен отличаться только логотипами:

FreeIPA включен в репозиторий Fedora 9. Все, что нужно для установки - это отдать команду:

yum install ipa-server

или

yum install ipa-client

При разработке версии 1 основное внимание было уделено централизованному управлению пользователями и аутентификацией. В следующих версиях будут добавлены функции централизованного управления сервисами, физическими и виртуальными машинами. Также будут реализованы централизованные политики управления sudoers и аудита.

Кроме того, Red Hat Enterprise IPA/Free IPA используется для аутентификации и авторизации в другом представленном на днях проекте Red Hat - решении для виртуализации на основе KVM - oVirt.

Ссылки:

http://www.redhat.com/promo/ipa/ - Страница Red Hat Enterprise IPA на сайте Red Hat
http://freeipa.org - Проект FreeIPA
http://www.markelov.net/articles.php?lng=ru&pg=2363 - мой обзор Fedora Directory Server, являющегося основой Red Hat Enterprise IPA и FreeIPA

Некоторые новшества в Fedora 9 с точки зрения SELinux

Месяц назад вышла девятая версия 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. Проведем эксперимент:

[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

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-бинарников.
Попробовать работу с режимом «киоска» можно установив пакет:

[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 портом.

[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:

[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.

Flask in OpenSolaris

На конференции Sun Tech Days 2008 удалось немного побеседовать с Glenn Faden касательно будущей реализации Flux Advanced Security Kernel (Flask) в OpenSolaris. По его словам, повторного использования кода/конвертора Reference Policy из SELinux не будет. Язык описания политик также будет свой (из-за несовместимости лицензий). Однако, он будет «очень похож». Проект пока находится в начальной стадии. Каких-либо новостей следует ожидать через несколько месяцев.

А Питер - отличное место для проведения подобных мероприятий :)

SELinux in news

Ru: Очередная поездка в Фарнборо (на этот раз для сдачи экзамена EX423 по RHDS), а сразу после этого двухнедельные курсы VMWare, спровоцировали появление 1000+ непрочитанных сообщений в заброшенной RSS-читалке. Разгребая эти залежи, не могу не отметить пару интересных новостей, касающихся SELinux.

Во-первых, проект OpenSolaris интегрирует использованную в SELinux схему безопасности Flask/Type Enforcement в свою операционную систему. Называется это дело Flexible Mandatory Access Control (FMAC), и имеет свою страничку на сайте проекта. Помимо Sun Microsystems, вклад в разработку FMAC вносит и АНБ – «родитель» SELinux. Таким образом, операционных систем, использующих данную модель безопасности, становиться все больше и больше. Не следует забывать и про существующую поддержку Flask/TE на уровне приложений, например СУБД (PostgreSQL) или средств виртуализации (гипервизор Xen).

Что касается конкурента SELinux от Novell - AppArmour, после увольнения лидера проекта и ряда ключевых разработчиков, этот самый лидер вовсе ушел в Microsoft. В общем, если вы смотрите в сторону MAC, то, наверно, это еще один аргумент в пользу SELinux.

Вторая новость менее значима, но тоже показательна: начало поддержки SELinux в популярнейшем дистрибутиве Ubuntu. По умолчанию, в отличие от RHEL/Fedora, в Ubuntu SELinux пока что выключен. Кстати, Ubuntu теперь потенциально можно считать удовлетворяющим требованиям сертификации LSPP/EAL4+.

Basic about SELinux

En: Here is selinux(8) man page (from libselinux) translation to Russian with some comments.

Ru: Как я и обещал, приступаю к переводам man-страниц, входящих в пакет libselinux. Первая на очереди - selinux(8). Хотя то, что в ней написано, так или иначе уже попадало в этот блог (в частности, пост "SELinux. Максимальный уровень защиты – бесплатно"), а также обсуждалось в других статьях на русском языке, man selinux:

selinux(8) SELinux Command Line documentation selinux(8)

НАЗВАНИЕ

selinux - Linux с улучшенной безопасностью (NSA Security-Enhanced Linux, SELinux)

ОПИСАНИЕ

Linux с улучшенной безопасностью (NSA Security-Enhanced Linux, SELinux) является реализацией гибко настраиваемого мандатного контроля доступа для операционной системы Linux. Архитектура SELinux обеспечивает поддержку различных видов политик мандатного контроля доступа, включая основанные на Type Enforcement®, Ролевом контроле доступа (Role-Based Access Control) и Многоуровневой безопасности (Multi-Level Security). Подробная информация и техническая документация, посвященная SELinux доступна по ссылке http://www.nsa.gov/selinux.

В конфигурационном файле /etc/selinux/config указывается включена или выключена система SELinux, а в случае если включена, то в каком режиме функционирует: принудительном (enforcing) или разрешительном (permissive). Это можно определить путем присвоения переменной SELINUX одного из значений: disabled, permissive или enforcing. Значение disabled полностью отключает код SELinux в ядре и приложениях, оставляя систему работать без защиты, обеспечиваемой SELinux. Значение permissive включает SELinux, однако все операции, которые могли бы быть запрещены в политике, разрешаются. При этом они документируются. Опция enforcing также включает SELinux. При этом запреты и отрабатываются, и документируются. Разрешительный режим может привнести сообщения о запретах, которые не встречаются в принудительном режиме. Это связанно с тем, что в принудительном режиме будут предотвращены операции выполняемые после первого же запрета. Кроме того, некоторые приложения после запрета доступа начинают работать в режимах с меньшими привилегиями.

Конфигурационный файл /etc/selinux/config также определяет, какая политика будет активной. Хотя SELinux позволяет установить в системе несколько альтернативных политик, только одна из них может быть активной в каждый конкретный момент времени. В настоящий момент времени существует два вида политик: целевая (targeted) и строгая (strict). (*) Целевая политика спроектирована таким образом, что на большинство процессов не накладывается никаких ограничений, и только некоторые службы работают в выделенных доменах безопасности, описанных в политике. К примеру, пользователь будет работать в ничем не ограниченном домене, но в то же время демон named или apache будут функционировать в своих доменах, учитывающих операции, выполняемые каждым конкретным демоном. Строгая политика спроектирована для четкого разграничения всех процессов, которые, в свою очередь, разделяются на отдельные домены безопасности. В будущем предполагается создание других политик (например, политики с поддержкой многоуровневой системы безопасности). Вы можете задать политику, которую хотите использовать, при помощи переменной окружения SELINUXTYPE в файле /etc/selinux/config. Соответствующие каждой такой политике настройки должны располагаться в своих директориях /etc/selinux/SELINUXTYPE/.

Заданная политика SELinux в дальнейшем может настраиваться при помощи набора опций, указываемых при компиляции, и переключателей (booleans), устанавливаемых во время исполнения. Утилита system-config-securitylevel (**) позволяет настраивать эти переключатели и опции.

Для ряда доменов, защищенных при помощи SELinux, существуют man-страницы, поясняющие, как производить настройку соответствующей политики.

МЕТКИ ФАЙЛОВ
С каждым файлом, директорией и устройством ассоциирована метка/контекст безопасности. Контекст хранится в расширенных атрибутах файловой системы. С SELinux часто возникают проблемы, если эти метки отсутствуют на файловой системе. Такая ситуация может быть вызвана при загрузкt машины с ядром, не поддерживающим SELinux. Если вы видите сообщение об ошибке, содержащее file_t, то с большой долей вероятности можно сказать, что у вас возникли серьезные проблемы, связанные с метками файловой системы.

Наилучший способ обновить метки на файловой системе - создать файл-тригер /.autorelabel и перезагрузить систему. То же самое можно проделать при помощи утилиты system-config-securitylevel. Для обновления меток отдельных файлов можно воспользоваться утилитами restorcon и fixfiles.

АВТОРЫ
Эту страницу руководства написал Dan Walsh.
Перевод руководства - Андрей Маркелов, 2008 г.

СМОТРИ ТАКЖЕ (***)
booleans(8), setsebool(8), selinuxenabled(8), togglesebool(8), restorecon(8), setfiles(8), ftpd_selinux(8), named_selinux(8), rsync_selinux(8), httpd_selinux(8), nfs_selinux(8), samba_selinux(8), kerberos_selinux(8), nis_selinux(8), ypbind_selinux(8)

ФАЙЛЫ
/etc/selinux/config

dwalsh at redhat dotcom 29 Апр 2005 selinux(8)

Необходимые замечания к man-странице:
(*) Справедливо для старых версий. В дистрибутивах c Fedora Core 5 по Fedora 7 и RHEL 5 поставлялось три набора политик (targeted, strict и MLS). В последней версии - Fedora 8 - политики strict и targeted объединены. Таким образом, в настоящий момент времени существуют два вида политик: целевая (targeted) и политика с поддержкой многоуровневой системы безопасности (MLS).
(**) В последних версиях Fedora Core/Fedora, а также в RHEL 5 для этих целей используется новая GUI утилита system-config-selinux.
(***) Для всех упомянутых man-страниц существует перевод на русский язык.

Russian policycoreutils translation

En: As a selinux-policy, policycoreutils in Fedora 8 now have Russian man pages (since package version 2.0.33-2). Thanks Anton Arapov and Andrew Martynov for corrections! My next goal for translation is libselinux.

Ru: Со вчерашнего дня в Fedora 8 доступны переводы справочной документации по пакту policycoreutils:

[root@andrey ~]# rpm -ql policycoreutils | grep "ru/man"
/usr/share/man/ru/man1
/usr/share/man/ru/man1/audit2allow.1.gz
/usr/share/man/ru/man1/secon.1.gz
/usr/share/man/ru/man8
/usr/share/man/ru/man8/audit2why.8.gz
/usr/share/man/ru/man8/chcat.8.gz
/usr/share/man/ru/man8/fixfiles.8.gz
/usr/share/man/ru/man8/genhomedircon.8.gz
/usr/share/man/ru/man8/load_policy.8.gz
/usr/share/man/ru/man8/open_init_pty.8.gz
/usr/share/man/ru/man8/restorecon.8.gz
/usr/share/man/ru/man8/restorecond.8.gz
/usr/share/man/ru/man8/run_init.8.gz
/usr/share/man/ru/man8/semanage.8.gz
/usr/share/man/ru/man8/semodule.8.gz
/usr/share/man/ru/man8/semodule_deps.8.gz
/usr/share/man/ru/man8/semodule_expand.8.gz
/usr/share/man/ru/man8/semodule_link.8.gz
/usr/share/man/ru/man8/semodule_package.8.gz
/usr/share/man/ru/man8/sestatus.8.gz
/usr/share/man/ru/man8/setfiles.8.gz
/usr/share/man/ru/man8/setsebool.8.gz

Спасибо Андрею Мартынову и Антону Арапову за исправления и комментарии. Следующая цель для переводов - libselinux.

Confining Samba with SELinux (in Russian)

En: As Dan Walsh wrote he started updating the man pages for different confined domains. So, I will update Russian version because now in Fedora 8, Russian man pages are still based on old version of man pages.

Ru: Страницы руководств по сконфигурированным (для которых существует политика SELinux) доменам не обновлялись с 2005 года. Недавно Dan Walsh начал переписывать ряд руководств, приводя описание к современному состоянию политик. Обновленная страница samba_selinux уже в Fedora 7/8. Перевод же в дистрибутиве пока не доступен (точнее, там мой старый перевод на основе старого же оригинала). Новый:

$ man samba_selinux

samba_selinux(8) Samba Selinux Policy documentation samba_selinux(8)

НАЗВАНИЕ

samba_selinux - Защита Samba при помощи SELinux

ОПИСАНИЕ
Security-Enhanced Linux обеспечивает защиту сервера Samba при помощи гибко настраиваемого мандатного контроля доступа. По умолчанию политика SELinux для Samba использует принцип наименьших привилегий. Для настройки того, как SELinux работает с Samba, существует ряд переключателей (booleans) и контекстов файлов.

ОБЩИЙ ДОСТУП К ФАЙЛАМ
SELinux требует наличия у файлов расширенных атрибутов, определяющих тип файла. Политика управляет видом доступа демона к этим файлам. Когда вы предоставляете общий доступ к файлам, у вас есть несколько вариантов как пометить файлы. Если вы хотите предоставить общий доступ к файлам/директориям за пределами домашних или стандартных директорий, этим файлам/директориям необходимо присвоить контекст samba_share_t. Например, при создании специальной директории /var/eng, необходимо установить контекст для этой директории при помощи утилиты chcon.

# chcon -R -t samba_share_t /var/eng

Однако назначенные таким образом метки не сохранятся при выполнении операции обновления меток. Наилучшее решение - сделать эти изменения постоянными. Для этого требуется рассказать системе SELinux об этих изменениях. Команда semanage может изменить назначенный по умолчанию контекст файлов на вашей машине. А команда restorecon прочтет файл file_context и установит описанные контексты для файлов и директорий..

# semange fcontext -a -t samba_share_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng

ОБЩИЙ ДОСТУП К ДОМАШНИМ ДИРЕКТОРИЯМ
По умолчанию политика SELinux запрещает удаленный доступ к домашним директориям. Если вы настроили эту машину как сервер Samba и желаете предоставить доступ к домашним директориям, вы должны установить переключатель samba_enable_home_dirs.

# setsebool -P samba_enable_home_dirs 1

СОВМЕСТНОЕ ВЛАДЕНИЕ ФАЙЛАМИ
Если вы хотите организовать между несколькими доменами (Apache, FTP, rsync, Samba) совместный доступ к файлам, то вы можете установить контекст файлов в public_content_t и public_content_rw_t. Данный контекст позволяет любому из выше перечисленных демонов читать содержимое. Если вы хотите, чтобы конкретный домен имел право записи в домен public_content_rw_t, вы должны установить соответствующий переключатель allow_ДОМЕН_anon_write. Таким образом, для samba вы должны выполнить:

# semange fcontext -a -t public_content_rw_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng
# setsebool -P allow_smbd_anon_write 1

ОБЩИЙ ДОСТУП К СИСТЕМНЫМ ФАЙЛАМ
Замечание: Вы не должны применять действия, описанные выше, к стандартным или домашним директориям! Например, директориям, принадлежащим RPM. Если вы хотите сделать /usr доступным через Samba, то изменение контекста этой директории и всех поддиректорий на samba_share_t - плохая идея. Дело в том, что другие сконфигурированные домены не смогут получить доступ на чтение к /usr, что может вызвать катастрофические последствия для машины. Для предоставления общего доступа к стандартным директориям существуют два переключателя (booleans). Если вы хотите предоставить общий доступ только на чтение к любой стандартной директории, вы можете установить переключатель samba_export_all_ro.

# setsebool -P samba_export_all_ro 1

Данный переключатель позволяет Samba прочесть каждый файл в системе. Аналогично, если вы хотите предоставить общий доступ Samba ко всем файлам и директориям в системе, установите samba_export_all_rw

# setsebool -P samba_export_all_rw 1

Этот переключатель позволяет Samba читать и писать каждый файл в вашей системе. Таким образом, в случае компрометации Samba серверу может угрожать серьезная опасность.

ОБЩИЙ ДОСТУП К NFS ФАЙЛАМ
По умолчанию политика SELinux запрещает демонам Samba чтение/запись nfs ресурсов. Если вы используете Samba для предоставления общего доступа к файловым системам NFS, то вам нужно включить переключатель samba_share_nfs

# setsebool -P samba_share_nfs 1

ИСПОЛЬЗОВАНИЕ CIFS/SAMBA ДЛЯ РАЗМЕЩЕНИЯ ДОМАШНИХ ДИРЕКТОРИЙ
Политика SELinux для Samba запрещает любому сконфигурированному приложению доступ к удаленным samba-ресурсам, смонтированным на вашей машине. Если вы хотите использовать удаленный сервер Samba для хранения домашних директорий вашей машины, то необходимо установить переключатель use_samba_home_dirs.

# setsebool -P use_samba_home_dirs 1

СКРИПТЫ SAMBA
Samba можно настроить для исполнения пользовательских скриптов. По умолчанию если вы инсталлируете такие скрипты в /var/lib/samba/scripts, то они будут помечены как samba_unconfined_script_exec_t. Так как эти скрипты могут использоваться для различных действий в системе, вы можете запускать их как несконфигурированные. Но при этом вам необходимо включить переключатель samba_run_unconfined

# setsebool -P samba_run_unconfined 1

Если вы пишете собственную политику, в файле samba.if описан интерфейс, называемый samba_helper_template(APP). Этот интерфейс создает файловый контекст samba_APP_script_exec_t, и домен samba_APP_script_t. Samba запускает скрипт, помеченный samba_app_script_exec_t, в домене samba_APP_script_t. Далее при помощи audit2allow вы можете создать политику для своего скрипта.

ИСПОЛЬЗОВАНИЕ SAMBA В КАЧЕСТВЕ КОНТРОЛЛЕРА ДОМЕНА
Если вы хотите использовать samba как контроллер домена, то есть добавить машины в файл passwd на сервере под управлением Linux, вам нужно включить переключатель samba_domain_controller. Это позволит демону Samba запускать и осуществлять переход в домены утилит passwd, useradd и groupadd. Данные утилиты предназначены для манипуляций базой данных passwd.

УТИЛИТА С ГРАФИЧЕСКИМ ИНТЕРФЕЙСОМ system-config-selinux
Для управления всеми описанными выше контекстами файлов и переключателями SELinux можно использовать утилиту с графическим интерфейсом system-config-selinux.

АВТОРЫ
Эту страницу руководства написал Dan Walsh.
Перевод руководства - Андрей Маркелов, 2007г.

СМОТРИ ТАКЖЕ
selinux(8), semanage(8), samba(7), chcon(1), setsebool(8), restorecon(8),

dwalsh at redhat com 9 Ноября 2007 samba_selinux(8)

Руководство по безопасности RHEL5

На днях NSA (АНБ) опубликовало руководство по настройке безопасной конфигурации RHEL 5 (читай Fedora, Scientific Linux, CentOS, StartCom и т.д.). Руководство в формате PDF доступно здесь. В объеме 170 страниц изложены пошаговые рекомендации, затрагивающие множество вопросов, начиная с защиты системы в целом и заканчивая конкретными службами.

Часть 2.2. SELinux. MLS и MCS: что с чем едят. MCS

Разберемся, что такое 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. К сожалению, в основном все на английском языке. Русскоязычных статей и переводов явный недостаток.

Часть 2.1. SELinux. MLS и MCS: что с чем едят. MLS.

Продолжаем разговор, начатый постом «Часть 1. SELinux. Максимальный уровень защиты – бесплатно».

Вслед за сообщениями о сертификации Red Hat Enterprise Linux 5 по Common Criteria EAL4+ (c расширениями LSPP, RBACPP и CAPP) на серверах HP и IBM, компания HP объявила о начале предоставления услуги поддержки конфигурации RHEL с включенной многоуровневой системой безопасности (multilevel security -MLS).

Что здесь понимается под MLS? MLS – это еще одна форма принудительного контроля доступа (mandatory access control - MAC), доступная нам при использовании SELinux. Политика с поддержкой MLS является опциональной и для большинства пользователей она будет намного менее полезной, чем принудительный контроль на основе Type Enforcement (TE) – основного механизма, используемого в SELinux. Но MLS – это «пропуск» для операционной системы в государственные и военные организации, где без такого рода разграничения полномочий не обойтись.

Политика MLS базируется на формальной модели Bell-LaPadula. В терминах этой модели все субъекты (для простоты - процессы) и объекты (файлы) имеют свой уровень допуска. Субъект с определенным уровнем допуска имеет право читать и создавать (писать/обновлять) объекты с тем же уровнем допуска. Кроме того, он имеет право читать менее секретные объекты и создавать объекты с более высоким уровнем. Субъект никогда не сможет создавать объекты с уровнем допуска ниже, чем он сам имеет, а также прочесть объект более высокого уровня допуска.

Уффф… Надеюсь, я вас не запутал. По-английски это формулируется намного короче:
«write up, read down» и «no write down, no read up».

Для поддержки MLS традиционный контекст SELinux, состоящий из трех частей: пользователь, роль и тип, был дополнен уровнем допуска. Уровень допуска состоит из диапазонов чувствительности данных (например, «секретно», «ДСП») и категорий данных («отдел кадров», «отдел финансовой отчетности»). Подробно мы поговорим об уровнях доступа, когда речь зайдет о мульти-категорийной безопасности (MCS), которую можно использовать и в «умолчальной» целевой политике.

Переходим к техническим деталям реализации, а вернее – к эксперименту с их использованием. Как опциональная, политика MLS доступна начиная с Fedora Core 5. Именно тогда разработчики перешли с использования оригинальной Example Policy на Reference Policy от Tresys. MLS нельзя установить интерактивно через Anaconda (но можно установить при использовании kickstart-файла). На установленной системе даем команду

yum –y install selinux-policy-mls

Тем самым мы устанавливаем базовый модуль MLS, появившийся в RHEL третьим после «целевой» (targeted) и «строгой» (strict) политики. Собственно, этот третий вариант политики и появился в RHEL для соответствия сертификации EAL4+ LSPP. Данная политика поддерживает принудительный контроль доступа TE, RBAC, и, естественно, модель Bell-LaPadula. Далее нам нужно поправить /etc/sysconfig/selinux, сказав, что теперь используется наша новая политика MLS. Меняем policy=targeted на policy=mls. Теперь, поскольку все файлы на существующей ФС создавались во время работы «целевой» (targeted) политики, нам необходимо обновить SELinux-контексты для всех файлов. Самый простейший/правильный способ – команды

touch /.autorelabel; init 6

Когда появиться меню загрузчика GRUB, нажмите «a», и в конец строки, определяющей параметры загрузки ядра, добавьте enforcing=0. Это (естественно, только на время до перезагрузки) переведет SELinux в «разрешительный» режим, когда правила отрабатываются и файлы создаются с правильным контекстом безопасности, но ограничения, налагаемые политикой SELinux, не применяются. Нам это нужно для того, чтобы ничто не помешало обновить контекст безопасности файлов. Ваша система загрузиться так, если бы SELinux был отключен, и все контексты будут обновлены (если вы не ошиблись при наборе touch /.autorelabel) . Теперь настало время снова перезагрузится, но уже без параметра enforcing=0. Перед перезагрузкой убедитесь, что работает демон sshd. В принципе можно обойтись и без перезагрузки, зайдя в текстовую консоль как пользователь root и отдав команду


setenforce 1

Кстати, выбор политики и необходимость обновления контекста безопасности файлов во время перезагрузки можно произвести из GUI, используя system-config-selinux.



После перезагрузки зайдите на машину по ssh. Дает ли доступ к привилегиям команда su? А sudo? А получится ли перевести SELinux в «разрешительный» режим или вообще выключить? Нет. Попробуйте создать файл из-под учетной записи root, а потом простым пользователем посмотреть его метаданные командой ls. «Вместо строчки – только точки».
Также после перезагрузки вы уже не сможете работать с X Window (как не запустится и ряд других служб). Хотя бы из-за того, что будет существовать возможность скопировать информацию из окна терминала с высоким уровнем допуска в терминал с низким.

Привести свою тестовую (подчеркиваю, тестовую!) систему в исходное состояние вы сможете снова перегрузившись с параметром ядра enforcing=0 и выбрав «целевую» политику.

Написание «строгой» MLS политики весьма сложная и комплексная задача. И от версии к версии политика становиться более гибкой, охватывая большее число служб. Для простого пользователя многоуровневая безопасность – излишество. Для большинства задач достаточно того уровня безопасности, который достигается при использовании включенной по умолчанию «целевой» политики SELinux. Однако, и в рамках «целевой» политики можно использовать реализацию мульти-категорийной безопасности (MCS), о чем мы и поговорим в продолжении этого поста «Часть 2.2. SELinux. MLS и MCS: что с чем едят. MCS». А пока ждем выхода Fedora 8! ;)


Кстати, благодаря Dan Walsh, там уже должны появиться некоторые из моих переводов руководств по SELinux на русском.