Dan Walsh, отвечающий в Red Hat за развитие SELinux опубликовал на Linux.com статью, посвященную использованию SELinux совместно с брандмауэром. Ссылка.
Показаны сообщения с ярлыком SELinux. Показать все сообщения
Показаны сообщения с ярлыком SELinux. Показать все сообщения
17 марта 2011
01 сентября 2009
Развитие проекта 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.
В изначально реализованной политике для 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.
09 февраля 2009
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.
Что означает все выше сказанное? Возможно в будущем те уникальные преимущества в плане защищенности, доступные в операционных системах общего назначения с открытым исходным кодом, станут преимуществами систем виртуализации с открытым кодом.
Теперь снова вернемся к более простому и традиционному случаю - получению привилегий на отдельно стоящем сервере/ОС. Данная проблема более традиционна, и для ее решения уже существуют технологии. Благодаря таким решениям, ряд операционных систем общего назначения, например, уже получило высокий уровень сертификации Common Сriteria EAL4+ (c расширениями LSPP, RBACPP и CAPP).
Такие "заклинания", как мандатный контроль доступа (MAC), многоуровневая система безопасности (MLS), мульти-категорийная безопасность (MCS) уже не раз встречались в моем блоге в контексте операционной системы. Я не буду повторяться, и просто дам ссылку на посты с тегом "SELinux", где я и писал про практическую реализацию ограничений привилегий системного администратора :) Итак, идея состоит в том, чтобы защитить гипервизор при помощи существующих решений мандатного контроля доступа.
Теперь вернемся к конкретике :) Проект sVirt, направленный на решение этой задачи, был анонсирован Джеймсом Моррисом в рассылке libvirt в августе прошлого года. Цель проекта - интеграция SELinux и виртуализации на основе Linux-ориентированных технологий. Недостаточность традиционного дискреционного контроля доступа в системах, требующих особой защищенности, обуславливается тем, что субъект может менять собственную политику безопасности. С другой стороны, если гостевые операционные системы будут изолированы при помощи политик мандатного контроля доступа, то это резко снижает возможный ущерб от успешной атаки, а то и вовсе ее предотвращает. В идеале в каждом процессе виртуальная машина должна работать в собственном контексте безопасности. Снова в качестве иллюстрации посмотрим на отдельную - не виртуализированную - операционную систему. Вы без труда найдете примеры, когда реальные уязвимости, затрагивающие ОС, в том или ином компоненте операционной системы с отключенным SELinux успешно блокировались политикой безопасности при включенном мандатном контроле.
К своей первой версии sVirt должен обеспечивать реализацию MAC на уровне ядра гипервизора, и обеспечивать простую изоляцию виртуальных машин, не требуя никакой настройки, т.е. все должно работать "из коробки". Ресурсы каждой гостевой операционной системы должны иметь свой уникальный контекст virtd_isolated_t:
В каком состоянии находится проект сейчас? Сделана низкоуровневая интеграция с libvirt, базовая поддержка в virsh, и виртуальные машины могут запускаться в своих контекстах безопасности. Как и в случае с oVirt, в первую очередь работа идет над KVM.
Что означает все выше сказанное? Возможно в будущем те уникальные преимущества в плане защищенности, доступные в операционных системах общего назначения с открытым исходным кодом, станут преимуществами систем виртуализации с открытым кодом.
25 декабря 2008
07 октября 2008
SELinux User Guide для Fedora 10
Релиз Fedora 10 не за горами, и уже сейчас желающие могут протестировать бета-версию дистрибутива. Еще одна бета-версия, но уже руководства по SELinux для Fedora 10, также доступна для ознакомления уже сейчас. Security-Enhanced Linux User Guide особенно актуален с учетом относительного «информационного голода» в том, что касается данной реализации системы мандатного контроля доступа. Приятного чтения.
28 августа 2008
Новый "Мастер" в system-config-selinux
Ден Уолш рассказал о добавлении в утилиту system-config-selinux мастера Boolean Lockdown Wizard. Он позволяет включать/выключать/сбрасывать в значение по умолчанию переключатели SELinux (booleans). Самое приятное отличие этого мастера от пункта Boolean в system-config-selinux - это возможность на финальном шаге через GUI сохранить текущее значение переключателей в файл.
Когда поддержка сформированных таким образом файлов будет добавлена в IPA, системный администратор сможет централизованно применять соответствующие настройки ко всем или части машин на предприятии.
Пока же можно воспользоваться командой:
[root@f9 ~]# semanage boolean -m -F my_boolean_file.txt
[root@f9 ~]# semanage boolean -m -F my_boolean_file.txt
Обновленный пакет находится в репозитории updates-testing. Чтобы попробовать работу с новым мастером, нужно включить этот репозиторий.
03 июля 2008
Новая статья в 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.
в утилите system-config-selinux можно модифицировать существующий тип пользователя и как добавить новый.
В первом примере модифицируется политика для xguest, позволяя этому пользователю не только запускать браузер, но и работать с IM по протоколу
AIM/AOL. Во втором примере создается новый тип пользователя, которому разрешено пользоваться терминалом, отправлять почту и читать/писать
в /maildir.
Отличная статья для первоначального знакомства с некоторыми расширенными в Fedora 9 функциями GUI-утилиты system-config-selinux.
17 июня 2008
Некоторые новшества в 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. Проведем эксперимент:
Собственно, тип 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.
20 марта 2008
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+.
Во-первых, проект 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+.
03 февраля 2008
Run VMware Server 2.0 Beta on Fedora 8 (and SELinux)
Ru: Получив на работе новый ноутбук (HP Compaq 6715b) я, приступил к приведению его в пригодное для работы состояние – установке Fedora. Проблем почти не возникло, за исключением того, что вместо драйвера для интегрированной видеокарты от ATI из livna, пришлось вручную скачать и установить более свежий драйвер с сайта производителя, поскольку лежащий в livna не захотел работать с «широкоформатными» разрешениями экрана. Как оказалось, это известная проблема.
Единственное ПО, с которым пришлось повозиться достаточно долго, это VMware Server. В основном для «виртуальных лаб» я использую Xen, где у меня отлично «крутятся» несколько копий RHEL 4 и 5, но, по ряду причин, иногда запускаю и VMware (не для запуска Windows :). Причем проблема возникла там, где я ее совсем не ожидал, и, если бы не ветка в форуме, наверно, потерял бы еще некоторое время. Cервер после отключения ipv6 прекрасно установился, запускался, работал и не выдавал никаких ошибок при старте. Журналы операционной системы также были девственно чисты. Однако, при попытке зайти в Web UI, VMware Server выдавал сообщение: The server is not responding. Please check that the server is running and accepting connections. Помогло лишь полное отключение SELinux (!!!). Честно говоря, меня это решение совсем не устраивает. Почему и чем мешает работе сервера «разрешительный» режим SELinux, пока понять не могу. По идее ничего кроме деградации производительности происходить в этом случае не должно.
Единственное ПО, с которым пришлось повозиться достаточно долго, это VMware Server. В основном для «виртуальных лаб» я использую Xen, где у меня отлично «крутятся» несколько копий RHEL 4 и 5, но, по ряду причин, иногда запускаю и VMware (не для запуска Windows :). Причем проблема возникла там, где я ее совсем не ожидал, и, если бы не ветка в форуме, наверно, потерял бы еще некоторое время. Cервер после отключения ipv6 прекрасно установился, запускался, работал и не выдавал никаких ошибок при старте. Журналы операционной системы также были девственно чисты. Однако, при попытке зайти в Web UI, VMware Server выдавал сообщение: The server is not responding. Please check that the server is running and accepting connections. Помогло лишь полное отключение SELinux (!!!). Честно говоря, меня это решение совсем не устраивает. Почему и чем мешает работе сервера «разрешительный» режим SELinux, пока понять не могу. По идее ничего кроме деградации производительности происходить в этом случае не должно.
06 января 2008
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:
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-страниц существует перевод на русский язык.
Конфигурационный файл /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-страниц существует перевод на русский язык.
21 декабря 2007
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.
18 декабря 2007
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.
$ man 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)
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)
06 ноября 2007
Часть 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. Выполним команду
Первым указывается обязательный текущий уровень (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 во время их регистрации в системе, и ограничивают доступный набор ролей). Также в число настраиваемых элементов входит сопоставление контекстов безопасности для различных видов объектов, таких как: сетевые порты, интерфейсы, сетевые узлы (хосты), а также контексты файлов.
Вводим команду, показывающую существующие имена уровней безопасности:
Как и ожидалось, напротив уровня безопасности s0 у нас пробелы, что мы собственно и видим при выводе команды ls –Z. При помощи команды semanege с ключевым словом translation и опциями -a, -d и -m можно добавлять, удалять и модифицировать имена категорий. Пока что после каждого изменения необходимо перезапускать демон mcstransd. В отличие от уровней чувствительности данных, категории не представляют собой иерархической структуры. Точка в синтаксисе обозначает диапазон категорий, запятая отделяет диапазоны и отдельные категории.
Теперь посмотрим, к каким категориям разрешен доступ пользователям:
Рядовым пользователям по умолчанию разрешен доступ только к s0. Отлично, давайте добавим новую категорию.
Добавим категорию пользователю. Обратите внимание, что сейчас мы работаем с пользователями Linux (ключевое слово команды login) а не SELinux (ключевое слово user)
Теперь можно зайти пользователем butters, создать файл в /tmp, и посмотреть, сможет ли пользователь, не имеющий доступ к категории chaos, прочитать этот файл:
При этом в /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:
мы увидим, что с категориями она работать не умеет, а, значит, от чтения журналов нам все равно не уйти ;) Собственно, это и правильно. audit2allow в первую очередь предназначена для решения проблем с TE.
Можно удалить категорию chaos, чтобы позволить остальным доступ к файлу
Той же самой командой можно добавить категорию для файла. Если файлу назначено несколько категорий (точнее – уровней безопасности), то пользователь должен иметь доступ ко всем категориям для работы с файлом.
При проведении этого маленького эксперимента не пользуйтесь командой su. Заходите с новой консоли или по ssh. Дело в том, что su не меняет текущий SELinux-контекст пользователя:
Что теперь? А теперь мы используя нашу стандартную целевую политику, которая включена по умолчанию, мы можем запретить системному администратору просмотр не предназначенных для него файлов.
В двух словах идея такова:
1. Создаем специальную категорию и специальных пользователей (сотрудников отдела ИБ).
2. Даем доступ к специальной категории только этим специальным пользователям.
3. Присваиваем semanage эту категорию, а сотрудникам ИБ даем возможность запускать этот файл через sudo.
4. В зависимости от ситуации, также поступаем с chcon и chcat.
5. Закрываем пользователю root возможность зайти в систему. Ограничиваем физический доступ. Оставляем su.
6. Все равно остается ряд проблем :) Строгая и MLS политика в этой ситуации подходит лучше, но и описанный вариант – жизнеспособен.
В следующем посте я постараюсь сделать небольшой обзор всех доступных в интернет и в off-line источников информации посвященных 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Мы видим, что нам доступно 1024 категории и один тип чувствительности данных. Что это означает? Вспомним, как выглядел контекст безопасности в FС4 и RHEL4:
Sensitivities: 1 Categories: 1024
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. К сожалению, в основном все на английском языке. Русскоязычных статей и переводов явный недостаток.
04 ноября 2007
Часть 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 на русском.
Вслед за сообщениями о сертификации 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 на русском.
15 октября 2007
AppArmor от Novell больше "не от Novell"?
Когда говорят о мандатном контроле доступа (MAC) в Linux, обычно сравнивают Novell AppArmor (система более простая в использовании) и Fedora/RHEL SELinux (система, обеспечивающая более комплексную защиту). Так вот, на днях стало известно, что Novell уволил лидера проекта AppArmor Crispin Cowan вместе с еще четырьмя разработчиками, работавшими над этим проектом. Cowan, ошеломленный увольнением, не собирается бросать свое детище. Он создал консалтинговую компанию Mercenary Linux, и, видимо, ждет, когда ее кто-нибудь поглотит: "If somebody loves us and one day wants to acquire Mercenary, that's great."
26 сентября 2007
С переводами policycoreutils и selinux-policy закончил :)
Понемногу дело движется... Закончил переводы man-страниц policycoreutils (20 страниц) и selinux-policy (8 страниц). Соответственно, bug #250741 и bug #306521. Оттуда же можно скачать непосредственно сами переводы в tar.gz. Когда переводы появятся в самом дистрибутиве, как я понимаю, зависит от maintainer'а пакетов.
17 июля 2007
EAL4+ для RHEL5: HP не отстает от IBM
Выбор – это хорошо. "Железо" от HP, плюс RHEL5 (c включенным мандатным контролем доступа) вслед за IBM получило абсолютно такую же сертификацию Common criteria EAL4+ (c расширениями LSPP, RBACPP и CAPP), как и парой недель раньше - сервера "голубого гиганта".
16 июля 2007
Перевод man-страниц policycoreutils (SELinux)
Вечера вечером начал перевод man-страниц утилит из пакета policycoreutils (основные утилиты для работы с политиками SELinux). Двадцать руководств различного объема планирую закончить через 1-2 недели. В качестве некой основы в переводе терминов я взял .po-файл (который, кстати, "вытянут" из Fedora) из того же пакета. Однако, в сообщениях, выводимых утилитами, присутствуют не все встречающиеся термины. Поэтому приходиться пытаться подбирать какие-то русские термины.
В качестве сервиса для размещения общедоступных черновиков выбрал http://selinux.ru.googlepages.com/ - удобная служба от вездесущего Google для быстрого создания маленьких сайтов (до 100М). После перевода всех двадцати руководств, надеюсь, все это будет доступно в составе базового пакета в SELinux-enabled дистрибутивах. В настоящее время информация на страничке активно обновляется – комментарии/замечания/исправления крайне приветствуются.
В качестве сервиса для размещения общедоступных черновиков выбрал http://selinux.ru.googlepages.com/ - удобная служба от вездесущего Google для быстрого создания маленьких сайтов (до 100М). После перевода всех двадцати руководств, надеюсь, все это будет доступно в составе базового пакета в SELinux-enabled дистрибутивах. В настоящее время информация на страничке активно обновляется – комментарии/замечания/исправления крайне приветствуются.
29 июня 2007
Часть 1. SELinux. Максимальный уровень защиты – бесплатно
Пару недель назад в новостях промелькнуло сообщение о том, что Red Hat Enterprise Linux на серверах IBM получил уровень сертификации по безопасности EAL4 Augmented with ALC_FLR.3. Это наивысший уровень сертификации, который когда-либо достигался операционной системой. Кроме RHEL5 эта планка достигнута лишь Trusted Solaris. Такой уровень как правило не нужен при внедрениях в коммерческих организациях, но он открыл дорогу для участия в проектах связанных с правительственными и военными организациями США. До этого другие дистрибутивы Linux уже имели подтвержденный уровень доверия EAL4, но без сертификации Labeled Security Protection Profile (LSPP).
Что важно нам, «простым смертным», - нет необходимости платить никому ни копейки для того, чтобы получить на своей машине столь же высокий уровень защиты, какой требуется в военных ведомствах. Как известно, Enterprise Linux строится на кодовой базе Open Source проекта Fedora (прежнее название Fedora Core). Забавно, что в RHEL5 Server более 300 пакетов даже не пересобирались специально под Enterprise Linux – это видно по тегу fc6 в имени пакета (в RHEL5 тег - el5). Так что в ряде случаев общий не только код, но и сами «бинарники». Fedora же совершенно бесплатно доступна для скачивания. Сравнение Enterprise Linux и Fedora приведено здесь.
Итак, каким же образом обеспечивается соответствие столь высокому критерию безопасности? В немалой степени это стало возможным благодаря SELinux (Security-Enhanced Linux) - реализации системы мандатного контроля доступа (MAC), которая может работать (и работает по умолчанию) параллельно с классической дискреционной системой контроля доступа (DAC).
Оставаясь в рамках DAC, мы имеем фундаментальное ограничение в плане разделения доступа пользователей к ресурсам – доступ к ресурсам основывается на правах доступа пользователя. Это классические права rwx на трех уровнях – владелец, группа-владелец и остальные. Плюс к этому, POSIX ACL, которые лишь расширяют число уровней, на которых можно определить права, но не более.
Таким образом, любое приложение, запущенное с правами usera, теоретически может сделать все что угодно со всеми данными, к которым имеет доступ usera. И не важно, например, что данное приложение – это почтовая программа, которой нужно иметь доступ только к письмам usera. Эта программа будет иметь доступ и, например, к видеофайлам usera, и к картинкам usera. И мало того, что сама программа имеет доступ, но она же может и все эти данные сделать доступными остальным. Все становиться гораздо хуже, когда usera имеет UID=0 (то есть это root). Мы утыкаемся в классическую «проблему суперпользователя». В данном случае мы получаем всего лишь два уровня доступа: root и обыкновенные пользователи. Иными словами, становиться невозможным реализовать доступ с использованием минимально необходимых привилегий.
В MAC же права доступа определяются самой системой при помощи специально определенных политик. Если же говорить конкретно о рассматриваемой реализации – SELinux, то такие политики работают на уровне системных вызовов и применяются самим ядром (но можно реализовать и на уровне приложения). SELinux изначально был разработан АНБ США, а в настоящий момент является Open Source-проектом и входит в стандартное «ванильное» ядро Linux. Коммерческая поддержка доступна уже более двух лет в составе RHEL4.
SELinux действует после классической модели безопасности Unix. Иными словами, через SELinux нельзя разрешить то, что запрещено через права доступа пользователей/групп. Политики описываются при помощи специального гибкого языка описания правил доступа. В большинстве случаев правила SELinux «прозрачны» для приложений, и не требуется никакой их модификации. В состав Fedora/RHEL входят готовые политики, в которых права могут определяться на основе совпадения типов процесса (субъекта) и файла (объекта) – это основной механизм SELinux. Две других формы контроля доступа – доступ на основе ролей и на основе многоуровневой системы безопасности (например, ДСП, секретно, совершенно секретно).
Самый простой для работы и поддержки с точки зрения ИТ службы предприятия тип политики - так называемая «целевая» политика, разработанная в рамках проекта Fedora. Эта политика устанавливается и включается по умолчанию и в RHEL4, и в RHEL5 и является единственной, поддерживаемой Red Hat в составе стандартных контрактов поддержки, политикой. В рамках политики описано более 200 процессов, которые могут выполняться в RHEL5 (в RHEL4 описано намного меньше, в том числе httpd,squid,pegasus,Mailman,Named, dhcpd,mysqld, nscd,ntpd,portmap,postgresql,snmpd,syslogd,winbindd). Все, что не описано «целевой» политикой, выполняется в домене (с типом) unconfined_t. Процессы, работающие в этом домене, не защищаются SELinux. Таким образом, все сторонние пользовательские приложения будут без всяких проблем работать в системе с «целевой» политикой в рамках классических разрешений DAC.
Кроме «целевой» политики, в состав дистрибутива входит политика с многоуровневой моделью безопасности (с поддержкой модели Bell LaPadula). Коммерческая поддержка этой политики доступна в RHEL5 со специальной лицензией и только для серверных систем с ограниченным числом установленных пакетов и без X Window System. Именно системы с данной политикой теперь имеют сертификацию EAL4+/LSPP.
Третий вариант политики - «строгий». Тут действует принцип «что не разрешено, то запрещено». Политика основывается на Reference Policy от компании Tresys. Данная политика не имеет коммерческой поддержки в RHEL.
Что важно нам, «простым смертным», - нет необходимости платить никому ни копейки для того, чтобы получить на своей машине столь же высокий уровень защиты, какой требуется в военных ведомствах. Как известно, Enterprise Linux строится на кодовой базе Open Source проекта Fedora (прежнее название Fedora Core). Забавно, что в RHEL5 Server более 300 пакетов даже не пересобирались специально под Enterprise Linux – это видно по тегу fc6 в имени пакета (в RHEL5 тег - el5). Так что в ряде случаев общий не только код, но и сами «бинарники». Fedora же совершенно бесплатно доступна для скачивания. Сравнение Enterprise Linux и Fedora приведено здесь.
Итак, каким же образом обеспечивается соответствие столь высокому критерию безопасности? В немалой степени это стало возможным благодаря SELinux (Security-Enhanced Linux) - реализации системы мандатного контроля доступа (MAC), которая может работать (и работает по умолчанию) параллельно с классической дискреционной системой контроля доступа (DAC).
Оставаясь в рамках DAC, мы имеем фундаментальное ограничение в плане разделения доступа пользователей к ресурсам – доступ к ресурсам основывается на правах доступа пользователя. Это классические права rwx на трех уровнях – владелец, группа-владелец и остальные. Плюс к этому, POSIX ACL, которые лишь расширяют число уровней, на которых можно определить права, но не более.
Таким образом, любое приложение, запущенное с правами usera, теоретически может сделать все что угодно со всеми данными, к которым имеет доступ usera. И не важно, например, что данное приложение – это почтовая программа, которой нужно иметь доступ только к письмам usera. Эта программа будет иметь доступ и, например, к видеофайлам usera, и к картинкам usera. И мало того, что сама программа имеет доступ, но она же может и все эти данные сделать доступными остальным. Все становиться гораздо хуже, когда usera имеет UID=0 (то есть это root). Мы утыкаемся в классическую «проблему суперпользователя». В данном случае мы получаем всего лишь два уровня доступа: root и обыкновенные пользователи. Иными словами, становиться невозможным реализовать доступ с использованием минимально необходимых привилегий.
В MAC же права доступа определяются самой системой при помощи специально определенных политик. Если же говорить конкретно о рассматриваемой реализации – SELinux, то такие политики работают на уровне системных вызовов и применяются самим ядром (но можно реализовать и на уровне приложения). SELinux изначально был разработан АНБ США, а в настоящий момент является Open Source-проектом и входит в стандартное «ванильное» ядро Linux. Коммерческая поддержка доступна уже более двух лет в составе RHEL4.
SELinux действует после классической модели безопасности Unix. Иными словами, через SELinux нельзя разрешить то, что запрещено через права доступа пользователей/групп. Политики описываются при помощи специального гибкого языка описания правил доступа. В большинстве случаев правила SELinux «прозрачны» для приложений, и не требуется никакой их модификации. В состав Fedora/RHEL входят готовые политики, в которых права могут определяться на основе совпадения типов процесса (субъекта) и файла (объекта) – это основной механизм SELinux. Две других формы контроля доступа – доступ на основе ролей и на основе многоуровневой системы безопасности (например, ДСП, секретно, совершенно секретно).
Самый простой для работы и поддержки с точки зрения ИТ службы предприятия тип политики - так называемая «целевая» политика, разработанная в рамках проекта Fedora. Эта политика устанавливается и включается по умолчанию и в RHEL4, и в RHEL5 и является единственной, поддерживаемой Red Hat в составе стандартных контрактов поддержки, политикой. В рамках политики описано более 200 процессов, которые могут выполняться в RHEL5 (в RHEL4 описано намного меньше, в том числе httpd,squid,pegasus,Mailman,Named, dhcpd,mysqld, nscd,ntpd,portmap,postgresql,snmpd,syslogd,winbindd). Все, что не описано «целевой» политикой, выполняется в домене (с типом) unconfined_t. Процессы, работающие в этом домене, не защищаются SELinux. Таким образом, все сторонние пользовательские приложения будут без всяких проблем работать в системе с «целевой» политикой в рамках классических разрешений DAC.
Кроме «целевой» политики, в состав дистрибутива входит политика с многоуровневой моделью безопасности (с поддержкой модели Bell LaPadula). Коммерческая поддержка этой политики доступна в RHEL5 со специальной лицензией и только для серверных систем с ограниченным числом установленных пакетов и без X Window System. Именно системы с данной политикой теперь имеют сертификацию EAL4+/LSPP.
Третий вариант политики - «строгий». Тут действует принцип «что не разрешено, то запрещено». Политика основывается на Reference Policy от компании Tresys. Данная политика не имеет коммерческой поддержки в RHEL.
Графическая утилита настройки system-config-selinuxFedora и RHEL, безусловно, не единственные дистрибутивы, поддерживающие SELinux. Достаточно вспомнить Debian и Hardened Gentoo. Но, на мой взгляд, именно в Fedora/RHEL воспользоваться преимуществом мандатного контроля доступа наиболее просто «из коробки». Для удобства управления в состав дистрибутива входят графические утилиты управления и мониторинга от Red Hat и Tresys.
В дальнейших постах блога я предполагаю более подробно коснуться SELinux и привести ссылки на ресурсы в Интернет.
Update. Продолжение разговора о SELinux:
Часть 2.1. SELinux. MLS и MCS: что с чем едят. MLS.
Часть 2.2. SELinux. MLS и MCS: что с чем едят. MCS
Подписаться на:
Сообщения (Atom)