Ключевые слова:selinux, limit, linux, fedora, security, (найти похожие документы)
From: sapunidze.blogspot.com
Date: Mon, 25 Sep 2010 17:02:14 +0000 (UTC)
Subject: Усиление безопасности при помощи SELinux
Оригинал: http://sapunidze.blogspot.com/search/label/selinux
Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).
Лицензия: Creative Commons Attribution-Share Alike 3.0 Unported License.
Часть 1: пользователи SELinux
Источник перевода: SELinux Lockdown Part One: SELinux Users
В Fedora 11 Linux-пользователи по умолчанию сопоставляются
SELinux-пользователю unconfined_u. SELinux-пользователь unconfined_u, в
свою очередь, сопоставлен ролям unconfined_r и system_r и всем
доступным категориям (compartments) Multi Category Security.
Обе роли unconfined_r и system_r сопоставляются доменам безопасности
SELinux. Домены безопасности SELinux - это определенные окружения
безопасности для процессов в системе Linux.
Неограниченный домен безопасности - unconfined_t - зарезервированное
окружение для процессов, которые в значительной степени освобождены от
ограничений SELinux. Роль system_r сопоставляется доменам безопасности
для системных процессов.
SELinux-пользователь unconfined_u имеет доступ к роли system_r, чтобы
иметь возможность запускать системные процессы в своих доменах
безопасности. SELinux-пользователь unconfined_u работает в домене
безопасности unconfined_t через роль unconfined_r, которой он
сопоставлен.
Команда semanage позволяет добавлять, изменять и удалять сопоставления
между Linux- и SELinux-пользователями, так же как и другие настройки,
касающиеся управления SELinux. В качестве альтернативы для изменения
этих настроек можно использовать system-config-selinux, графический
интерфейс к semanage.
Чтобы с помощью команды semanage посмотреть какому SELinux-пользователю
по умолчанию сопоставлены Linux-пользователи наберите:
sudo semanage login -l | grep default
результат команды будет каким-то таким:
__default__ unconfined_u SystemLow-SystemHigh
В примере выше Linux-пользователи по умолчанию сопоставлены
SELinux-пользователю unconfined_u.
Чтобы изменить это и сопоставить Linux-пользователей по умолчанию
ограниченному SELinux-пользователю с именем user_u просто наберите:
sudo semanage login -m -s user_u "__default__"
В результате все новые Linux-пользователи будут по умолчанию
сопоставляться ограниченному SELinux-пользователю user_u.
Вы можете переопределить данное сопоставление при добавлении
Linux-пользователей командой useradd используя опцию -Z. Эта опция
определяет какому SELinux-пользователю должен быть сопоставлен
Linux-пользователь.
Например наберите:
sudo useradd -Z guest_u joe
В результате будет создан новый Linux-пользователь с именем joe,
который будет сопоставлен SELinux-пользователю guest_u, вместо
определенного по умолчанию SELinux-пользователя.
Также для изменения сопоставления между Linux-пользователем и
SELinux-пользователем может быть использована команда usermod с опцией -Z.
Существует несколько предопределенных профилей SELinux-пользователей.
Список данных профилей можно вывести командой semanage, наберите:
sudo semanage user -l
Далее я рассмотрю некоторые свойства этих предопределенных
SELinux-пользователей.
SELinux-пользователь guest_u:
Этот профиль используется для пользователей, которых необходимо
усиленно контролировать. SELinux-пользователь guest_u может только
войти в систему используя OpenSSH. Гостевые пользователи не имеют
доступа к сетевым ресурсам и программам с установленными битами setuid
и setgid.
SELinux-пользователь xguest_u:
Данный профиль аналогичен guest_u за исключением того, что Xguest
пользователи могут входить в Xwindow и не могут входить используя
OpenSSH. Другим исключением является то, что данный пользователь может
получить доступ к HTTP порту, используя контролируемый SELinux
экземпляр Mozilla Firefox.
SELinux-пользователь user_u:
SELinux-пользователь user_u напоминает обычного непривилегированного
ограниченного (confined) SELinux-пользователя. Такой пользователь может
войти в систему используя Xwindow и OpenSSH, имеет доступ к сетевым
ресурсам, но не может использовать программы с установленными битами
setuid и setgid.
SELinux-пользователь staff_u:
Этот SELinux-пользователь идентичен user_u, за исключением того, что
staff_u может использовать программы с флагами setuid и setgid. Кроме
того пользователь staff_u может также просмотреть информацию обо всех
процессах в системе и имеет некоторые другие несущественные привилегии
по сравнению с пользователем user_u.
SELinux-пользователь sysadm_u:
Данный пользователь придуман, чтобы ограничить используя SELinux
учетную запись root, что обычно делать не рекомендуется. Он
используется в Multi Level Security окружении, где нет пользователя
unconfined_u.
SELinux-пользователь unconfined_u:
SELinux-пользователь unconfined_u это среда, в которой по умолчанию
работают все Linux-пользователи в соответствии с целевой политикой
Fedora (Fedora Targeted policy). Этот пользователь в значительной
степени освобожден от ограничений, накладываемых SELinux. Исключением
является механизм Memory Execution Protections (ограничение на
исполнение определенных операций в памяти).
Если Вы хотите повысить безопасность вашей системы, тогда не следует
сопоставлять реальных Linux-пользователей, не пользователя root,
SELinux-пользователю unconfined_u. Во многих сценариях существование
неограниченных пользователей создает зияющую дыру в безопасности.
Вход пользователя root должен быть запрещен. Root должен иметь
возможность войти с терминала только в случае крайней необходимости. В
Fedora, Linux-пользователь root сопоставлен unconfined_u. Это означает,
что root практически не защищается SELinux.
Чтобы повысить безопасность использования root можно сопоставить
пользователя root SELinux-пользователю sysadm_u. Хотя это не сильно
увеличивает безопасность по сравнению с unconfined_u и root будет иметь
возможность обойти ограничения SELinux.
Итог - вход от имени пользователя root должен быть запрещен, за
исключением входа с терминала в крайних случаях.
SELinux-пользователь system_u:
Этот пользователь зарезервирован для нужд системы. Обычные
Linux-пользователи не должы сопоставляться с SELinux-пользователем
system_u.
Как определить SELinux-пользователя по умолчанию для новых
Linux-пользователей объяснили, как переопределить сопоставление по
умолчанию с использованием команды useradd и опции -Z тоже объяснили.
Выше было рассказано о доступных предопределенных SELinux
пользователях. Осталось показать как можно изменить сопоставление
SELinux-пользователя Linux-пользователям.
Вывести список всех сопоставлений между Linux- и SELinux-
пользователями:
sudo semanage login -l
Сопоставить Linux-пользователя SELinux-пользователю:
sudo semanage login -a (...)
Изменить сопоставление межд Linux-пользователем и
SELinux-пользователем:
sudo semanage -m (...)
Удалить сопоставление между Linux-пользователм и SELinux-пользователем:
sudo semanage -d (...)
Вывод:
Для повышения безопасности системы настройте SELinux, чтобы по
умолчанию Linux-пользователи сопоставлялись ограниченным
SELinux-пользователям.
Запретите вход пользователю root в систему с использованием OpenSSH и
Xwindow. Разрешите пользователю root входить только в крайних случаях,
используя терминал. Либо оставьте root сопоставленным
SELinux-пользователю unconfined_u или сопоставьте его пользователю
sysadm_u (например, если вы решите деинсталлировать модуль SELinux
unconfineduser).
Сопоставьте ваших Linux-пользователей наиболее подходящим ограниченным
профилям SELinux-пользователей.
Используйте команду useradd и опцию -Z, чтобы добавлять
Linux-пользователей, переопределяя сопоставление, определенное по
умолчанию, передавая имя SELinux-пользователя в качестве аргумента.
Часть 2. Разрешающий режим SELinux
Источник на английском: SELinux Lockdown Part Two: PAM SEPermit
Источник на русском: http://sapunidze.blogspot.com/2009/06/selinux-2-pam-sepermit.html
Разрешающий режим SELinux (Permissive Mode) это состояние, в котором
ограничения SELinux не осуществляются. Однако, SELinux регистрирует
нарушения политики SELinux, которые бы в нормальном состоянии
предотвращались. Воспринимайте разрешающий режим как систему
обнаружения вторжений (Intrusion Detection System), тогда как
принудительный режим (Enforcing Mode) можно рассматривать как систему
предотвращения вторжений (Intrusion Prevention System).
В большинстве случаев система на время работы в разрешающем режиме
будет выведена из эксплуатации. В некоторых ситуациях это может быть
не так просто сделать.
Существуют способы минимизировать риски, связанные с разрешающим
режимом. Предпочтительным способом является недавно представленная
возможность с названием разрешающие домены SELinux (SELinux
Permissive Domains). Разрешающие домены будут обсуждаться позже.
Подключаемый модуль аутентификации (Pluggable Authentication Module)
с названием SEPermit может также помочь минимизировать незащищенность
разрешающего режима. PAM SEPermit может заблокировать вход
Linux-пользователю, когда система работает в разрешающем режиме.
Рассмотрим систему, в которой Linux-пользователи ограничены SELinux.
Разрешающий режим фактически снимает эти ограничения.
Linux-пользователи могут воспользоваться этими преимуществами и
получить доступ к ресурсам, которые в ином случае были бы для них не
доступны.
PAM SEPermit включен по умолчанию в Fedora 11 в различных файлах в
/etc/pam.d/, например, в /etc/pam.d/sshd. Чтобы заблокировать
возможность входа Linux-пользователя в разрешающем режиме достаточно
в конфигурацию SEPermit, расположенную в /etc/security/sepermit.conf,
добавить Linux- или SELinux- пользователей.
Например, при добавлении %user_u в файл sepermit.conf в
/etc/security, блокируется вход SELinux-пользователю user_u, при
работе системы в разрешающем режиме.
Имейте в виду, что разрешающий режим работы SELinux также снимает
ограничения SELinux и для не пользовательских процессов, таких как
системные службы. В большинстве случаев рекомендуется перенести вашу
систему из демилитаризованной зоны на время работ по устранению
проблем в разрешающем режиме. Хотя PAM SEPermit может быть полезен в
некоторых случаях.
Побробуйте!
Вывод: Отдавайте предпочтение разрешающим доменам (Permissive Domains)
SELinux, а не разрешающему режиму работы SELinux (Permissive Mode).
Если разрешающий режим требуется в промышленной среде на системе с
Linux-пользователями, ограниченными с использованием SELinux,
поощряется блокировка входа Linux-пользователей с использованием
подключаемого модуля аутентификации SEPermit.
Учитывайте, что это окажет влияние только на Linux-пользователей,
системные службы не будут защищаться SELinux в разрешающем режиме.
Часть 3: Permissive Mode Vs. Permissive Domains
Источник на английском: SELinux Lockdown Part Three: Permissive Mode Vs. Permissive Domains
Источник на русском: http://sapunidze.blogspot.com/2009/06/selinux-3-permissive-mode-vs-permissive.html
Продолжаю выкладывать перевод цикла статей по использованию SELinux.
Оригинал на английском языке опубликован в [9]блоге Доминика Грифта
(Dominick Grift).
Разрешающий режим SELinux (SELinux Permissive Mode) это состояние, в
котором SELinux разрешает нарушения политики SELinux на уровне всей
системы. В этом состоянии нарушения политики только регистрируются.
Разрешающий режим может быть использован для устранения неполадок и
тестирования проблем, связанных с SELinux. Трудности с разрешающим
состоянием на уровне всей системы связаны с разумной необходимостью
перевода системы в безопасную среду и вывода её из эксплуатации. В
некоторых редких случаях можно с целью минимизации рисков, вызванных
разрешающим режимом, рассмотреть подключаемый модуль аутентификации
(Pluggable Authentication Module) SEPermit, но часто данной меры
недостаточно, потому что он только запрещает вход Linux пользователям.
Системные службы остаются уязвимы к нарушениям политик.
Недавно с целью устранения данных проблем были представлены разрешающие
домены SELinux (SELinux Permissive Domains). С разрешающими доменами
можно перевести отдельный домен безопасности SELinux в разрешающее
состояние. Используя разрешающие домены можно оставить систему в
эксплуатации и, например, запретить доступ к данному домену при помощи
IPTables, TCP Wrappers, PAM или используя другие методы.
Для добавления и удаления разрешающих доменов SELinux используется
команда semanage. Вам не нужно знать в каком домене безопасности
работает процесс, чтобы сделать этот домен безопасности разрешающим
доменом. Команда ps с опцией -Z поможет узнать эту информацию.
Пример того как сделать разрешающим домен безопасности с названием
httpd_t для Apache:
sudo semanage permissive -a httpd_t
Пример того как сделать домен безопасности с названием httpd_t для
Apache снова принудительным:
sudo semanage permissive -d httpd_t
Пример того как используя команду semanage просмотреть разрешающие
домены SELinux:
sudo semanage permissive -l
Вывод:
Отдавайте предпочтение разрешающим доменам SELinux, а не разрешающему
режиму.
Добавляйте, просматривайте и удаляйте разрешающие домены с
использованием команды semanage.
Часть 4: Создание пользовательского домена SELinux
Источник на английском: SELinux Lockdown Part Four: Customized SELinux User Domain
Источник на русском: http://sapunidze.blogspot.com/2009/07/selinux-4-selinux.html
В первой главе этой серии рассматривались пользователи SELinux и
объяснялись некоторые свойства предопределенных пользователей
SELinux. В большинстве сценариев должно хватать возможностей данных
профилей. В случае если ни один из предопределенных SELinux
пользователей не подходит профилю пользователя Linux можно
реализовать новую ограниченную среду под свои определенные
требования.
Самый простой способ - взять за основу для нового пользовательского
домена SELinux (SELinux User Domain) существующий, а не создавать
новый с чистого листа. В этой статье будет показано как создать свой
пользовательский домен SELinux на основе ограниченного профиля
user_t. Также рассматриваются варианты сопоставления данного
пользовательского домена с заданным пользователем SELinux, чтобы
данному окружению сопоставить пользователей Linux, как это было
описано в главе SELinux Users.
Требуется: добавить ограниченного пользователя в систему с
требованиями, которые почти идентичны пользователю SELinux user_u.
Особенность заключается в том, что этот пользователь должен иметь
возможность просматривать содержимое точки монтирования /var.
Чтобы совершить задуманное необходимо создать новое окружение
пользователя SELinux на основе пользовательского домена user_t и
установить его в модуль политики SELinux (SELinux Policy Module). Мы
можем расширить данный модуль политики, позволив просматривать
содержимое директории /var, и мы можем создать сопоставление нового
пользовательского домена и нового пользователя SELinux. Чтобы вручную
сопоставить новый домен и нового пользователя SELinux, вместо
добавления сопоставления непосредственно в сам модуль политики, мы
можем использовать команду semanage.
Нам потребуется доступ к исходным текстам политики SELinux (SELinux
Source Policy) для использования их в качестве подсказки. В этом
примере будут использоваться исходные тексты политики SELinux,
свободно доступные по адресу
(http://oss.tresys.com/projects/refpolicy/browser/trunk/). Хотя в
нашем случае использование upstream-версии эталонной политики от
Tresys (Tresys Reference Policy) будет достаточным, следует отметить,
что в большинстве случаев нужно использовать специфичные для своего
дистрибутива исходные тексты политики SELinux.
Сначала посмотрим исходный текст пользовательского домена user_t в
тексте политики от Tresys:
(http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/roles/unprivuser.te)
Наш новый пользовательский домен (User Domain) с названием myuser_t
будет основан на модуле политики user_t. Для соответствия специфики
политики дистрибутива Fedora нужно внести несколько незначительных
изменений:
mkdir ~/myuser; cd ~/myuser;
echo "policy_module(myuser, 0.0.1)" > myuser.te;
echo "role myuser_r;" >> myuser.te;
echo "userdom_unpriv_user_template(myuser)" >> myuser.te;
Приведенной выше политикой создается новый ограниченный
пользовательский домен SELinux, почти идентичный user_t,
сопоставленный по умолчанию пользователю SELinux user_u. Добавим
политику, разрешающую просматривать содержимое точки монтирования
/var:
echo "files_list_var(myuser_t)" >> myuser.te;
Сопоставим программно наш пользовательский домен SELinux myuser_t
новому пользователю SELinux с названием myuser_u:
echo "gen_user(myuser_u, user, myuser_r, s0, s0)" >> myuser.te;
Заметим, что политика выше аналогична выполнению вручную следующей
команды semanage:
sudo semanage user -a -L s0 -r s0-s0 -R myuser_r -P user myuser_u
Политика для созданного пользовательского домена готова. Теперь
необходимо из исходной политики собрать бинарный модуль политики
SELinux:
make -f /usr/share/selinux/devel/Makefile
В качестве альтернативы можно использовать следующие команды, чтобы
собрать бинарный модуль политики:
checkmodule -M -m -o myuser.mod myuser.te
semodule_package -o myuser.pp -m myuser.mod
Установите вновь созданный бинарный модуль политики:
sudo semodule -i myuser.pp
В завершении следует определить для нашего нового SElinux
пользователя контекст безопасности SELinux (SELinux Security
Contexts) по умолчанию, чтобы программы входа знали какой домен
пользователя использовать:
cp /etc/selinux/targeted/contexts/users/user_u /etc/selinux/targeted/contexts/users/myuser_u
sed -i 's/user/myuser/g' /etc/selinux/targeted/contexts/users/myuser_u
Теперь мы можем просто добавить нового Linux пользователя и
сопоставить его нашему свежему SELinux пользователю myuser_u командой
useradd и опцией -Z или командой semanage и опцией -m.
Вывод: Вместо редактирования существующих по умолчанию создавайте
новых SELinux пользователей и домены пользователей SELinux.
Часть 5: SELinux RBAC
Источник на английском: SELinux Lockdown Part Five: SELinux RBAC
Источник на русском: http://sapunidze.blogspot.com/2009/07/selinux-5-selinux-rbac.html
В первой главе этой серии рассказывалось, что пользователи SELinux
сопоставляются пользовательским доменам и компонентам
мультикатегорийной безопасности (Multi Category Security - MCS). Эти
сопоставления могут настраиваться запуском команды semanage с опцией
user. Также сопоставления пользователя SELinux могут автоматически
настраиваться вызовом интерфейса gen_user() в файле с исходным
текстом модуля Type Enforcement (Type Enforcement Source Module) для
вашего домена пользователя.
SELinux RBAC используется для обеспечения возможности назначения
нескольких ограниченных окружений SELinux одному SELinux
пользователю.
В SELinux роли пользователя (User Roles) - это домены пользователя
или пользовательские домены (User Domains). Когда упоминаются роли
часто имеется в виду дополнительный (secondary) пользовательский
домен пользователя SELinux. Часто роли, предназначенные для
использования в качестве дополнительных доменов пользователя,
отличаются от основных (primary) доменов. Это объясняется тем, что
пользователи Linux фактически не используют для входа в систему роли,
созданные как дополнительные домены пользователя, .
Вместо этого пользователи Linux, используя команду sudo или
комбинацию команд su и newrole, осуществляют переключение домена или
доменный переход (Domain Transition) к их дополнительной роли.
Имейте в виду, что некоторые роли разрабатывались как основные домены
пользователей, тогда как другие поддерживают только функциональность
дополнительного домена пользователя. Первичные пользовательские
домены позволяют пользователю войти в систему, второстепенные домены
пользователей могут быть использованы только с командами sudo и su
вместе с newrole.
Роль Sysadm
Пример роли, предназначенной для использования в качестве основного
домена пользователя
SELinux пользователь sysadm_u сопоставлен роли sysadm_r. Это
сопоставление можно увидеть, выполнив команду:
sudo semanage user -l | grep sysadm_u
По умолчанию пользователи Linux, сопоставленные пользователю SELinux
sysadm_u, работают с ролью sysadm_r. В этом случае sysadm_r - это
основной домен пользователя.
SELinux пользователь staff_u также сопоставлен роли sysadm_r.
Основным пользовательским доменом пользователя SELinux staff_u
является (роль) staff_r. Контексты по умолчанию, определенные в
/etc/selinux/targeted/contexts/users/staff_u, определяют с какими
пользовательскими доменами пользователи будут подключаться по
умолчанию и с какими пользовательскими доменами пользователи могут
войти, указав домен пользователя при входе.
По умолчанию SELinux пользователь staff_u входит в систему в домен
пользователя staff_t. Роль sysadm_r, предназначенная для
использования в качестве основного домена пользователя, может быть
использована при входе, например, следующим образом:
ssh joe/[email protected]
Также роль sysadm_r может быть использована при переходе домена
выполнением команд sudo и su вместе с newrole, как это предусмотрено
для дополнительных доменов пользователей.
Пользовательский домен sysadm_t является окружением по умолчанию для
SELinux пользователя sysadm_u и предназначен для использования в
качестве дополнительного окружения для SELinux пользователя staff_u,
хотя даже SElinux пользователь staff_u может настроить подключаемый
модуль аутентификации (Pluggable Authentication Module) pam_selinux
для использования sysadm_t в качестве его основного домена
пользователя.
Роль Webadm
Пример роли, предназначенной для использования в качестве
дополнительного домена
В отличии от роли sysadm_r, пользовательский домен webadm_t не может
быть использован для непосредственного входа в систему. Вместо этого
его необходимо использовать из другого домена пользователя через
команды sudo или su вместе с newrole. Пользовательский домен webadm_t
не имеет разрешений, необходимых для запуск полноценного окружения
пользователя.
Для использования роли webadm_r, её следует сопоставить, например,
SELinux пользователю staff_u:
sudo semanage user -m -L s0 -r s0-s0:c0-c1023 -R "staff_r system_r webadm_r" -P user staff_u
Пожалуйста имейте в виду, что модификация существующих SELinux
пользователей не поощряется. Предпочтительно оставлять
предустановленных по умолчанию SELinux пользователей в их неизменном
виде. Вместо этого добавляйте новых созданных и настроенных под ваши
потребности SELinux пользователей:
sudo semanage user -a -L s0 -r s0-s0:c0-c1023 -R "staff_r system_r webadm_r" -P user webadm_u
cp /etc/selinux/targeted/contexts/users/staff_u /etc/selinux/targeted/contexts/users/webadm_u
В этом примере роль webadm_r может быть использована только как
дополнительный пользовательский домен по двум причинам. Во-первых,
пользовательский домен webadm_t не имеет достаточных полномочий для
поддержки полноценного окружения входа в систему. Во-вторых, для
нашего пользователя webadm_u за основу файла контекста по умолчанию в
/etc/selinux/targeted/contexts/users мы взяли файл контекста по
умолчанию пользователя staff_u. В этом файле пользовательский домен
webadm_t не является допустимым контекстом, используемым для входа в
систему.
Использование ролей для ограничения пользователя Root
Управление доступом на основе ролей (Role Based Access Control) может
использоваться для создания разных доменов пользователей с разными
правами и назначения этих ролей пользователям SELinux. Хотя RBAC
может использоваться как для непривилегированных так и для
привилегированных пользователей, чаще его используют для ограничения
привилегированного пользователя root.
Например, SElinux пользователь webadm_u, созданный выше, может быть
использован для ограничения Linux пользователя root до возможности
только управлять окружением Apache. Домен пользователя staff_t -
непривилегированный. Это означает, что при работе пользователя root в
пользовательском домене staff_t ему не доступны все полномочия root.
Пользовательский домен webadm_t - ограниченно привилегированный. При
работе пользователя root в пользовательском домене webadm_t ему
доступны некоторые ресурсы root, доступ к которым разрешен
ограниченным окружением webadm_t.
Например, некоторый пользователь сопоставлен SELinux пользователю
webadm_u. Ему также разрешены все полномочия пользователя root в
конфигурационном файле /etc/sudoers. При входе этого пользователя в
систему по умолчанию ему будет определен пользовательский домен
staff_t. Если он выполнит команду sudo как staff_t, то ему, например,
не будет разрешено перезапустить службу Apache.
Если он до перезапуска службы, используя команду sudo, совершит
переход в домен webadm_t, то у него всё получится:
sudo -r webadm_r -t webadm_t service httpd restart
Если же он попытается, используя команду sudo, изменить пароль
пользователя root, то он получит отказ, потому что ни staff_t, ни
webam_t не имеют таких привилегий.
Это мощная возможность, означающая, что теперь можно делегировать
ограниченные явно заданные привилегии без необходимости раздавать
пароль пользователя root. (прим. перев.: в оригинале у автора
написано - It means that it is not possible ("не возможно") to
delegate limited specified root privileges without having to share
roots password - считаю, что тут явно опечатка, комментарий оставлю
до получения ответа автора)
Далее рассказывается о некоторых предустановленных ролях.
Роль guest_r
Пользовательский домен, используемый только в качестве основного.
Описание пользователя SELinux guest_u приводится в первой части.
Роль xguest_r
Пользовательский домен, используемый только в качестве основного.
Описание пользователя SELinux xguest_u приводится в первой части.
Роль user_r
Пользовательский домен, используемый только в качестве основного.
Описание пользователя SELinux user_u приводится в первой части.
Роль staff_r
Пользовательский домен, используемый только в качестве основного.
Описание пользователя SELinux staff_u приводится в первой части.
Роль sysadm_r
Этот домен пользователя может быть использован и как основной, и как
дополнительный домен. Пользователь SELinux sysadm_u использует
sysadm_r в качестве роли по умолчанию, а SELinux пользователь staff_u
использует sysadm_r как дополнительную роль. Роль sysadm_r обладает
достаточными правами для обеспечения входа пользователей в систему.
Пользователь sysadm_u описывается в первой части.
Роль system_r
Эта роль используется системой в качестве основной. Пользователи
могут использовать роль system_r как дополнительную для перезапуска
системных служб в их надлежащем контексте.
Роль unconfined_r
Этот пользовательский домен может быть использован и как основной, и
как дополнительный домен. Пользователь unconfined_u описывается в
первой части.
Роль webadm_r
Этот пользовательский домен может быть использован только в качестве
дополнительного домена. Эта роль не имеет доступа к домашним
директориям пользователей и многие другие привилегии, необходимые для
обеспечения входа пользователей в систему. Данный домен пользователя
обладает необходимыми правами для управления окружением Apache.
Роль logadm_r
Этот пользовательский домен может быть использован только в качестве
дополнительного домена. Эта роль не имеет доступа к домашним
директориям пользователей и многие другие привилегии, необходимые для
обеспечения входа пользователей в систему. Данный домен пользователя
обладает необходимыми правами для управления окружением регистрации
событий (logging).
Часть 6: Создание ролей SELinux
Источник на английском: [[ SELinux Lockdown Part Six: Customized SELinux]]
Источник на русском: http://sapunidze.blogspot.com/2009/07/selinux-5-selinux.html
В четвёртой части серии описывался процесс создания пользовательских
доменов SELinux. Создание ролей осуществляется очень похожим
способом. ак уже отмечалось в предыдущей статье про RBAC: роли это
сопоставления к пользовательским доменам (прим. перев.: в оригинале -
Roles are mappings to User Domains, в отличии от автора я не живу в
Голландии, поэтому более удачного перевода пока не предумал).
Какие-то домены пользователей могут использоваться пользователями для
входа в систему, потому что эти домены, например, имеют полномочия по
доступу к домашней директории пользователя. Такие домены в предыдущей
части назывались основными (primary) пользовательскими доменами.
Другие домены созданы в качестве дополнительных. Пользователи,
используя команды sudo или su вместе с newrole, могут осуществить
доменный переход (Domain Transition) к этим дополнительным доменам.
Дополнительные домены не могут использоваться для входа в систему. В
этой части будет продемонстрировано как создается такой
дополнительный пользовательский домен. Целью является реализовать
привилегированную роль SELinux, которой предоставлены полномочия по
управлению DNS службой Bind. За основу будет взят пользовательский
домен webadm_t, обсуждавшийся ранее. Также будет пересмотрен
некоторый материал четвёртой части: Создание пользовательского домена
SELinux - чтобы разрешить доступ к новой роли bindadm_r, потребуется
изменить основной домен пользователя.
Начнём с создания нового дополнительного домена пользователя с
названием bindadm, основанного на предустановленном домене SELinux
webadm_t. Новый домен пользователя основан на двух файлах с исходным
текстом политики SELinux (SELinux Source Policy):
webadm.te и
webadm.if
Файлы исходных текстов политики SELinux с расширением ".te"
называются Type Enforcement файлы. Файлы с расширением ".if"
называются интерфейсными (Interface files). Файлы Type Enforcement
содержат описания (Declarations) и политику (Policy), персональные
или локальные для данного домена (Domain). Интерфейсные файлы
содержат описания и политики, общие для этого домена и других
доменов, желающими взаимодействовать с данным доменом.
mkdir ~/bindadm; cd ~/bindadm;
echo "policy_module(bindadm, 0.0.1)" > bindadm.te;
echo "role bindadm_r;" >> bindadm.te;
echo "userdom_base_user_template(bindadm)" >> bindadm.te;
echo "allow bindadm_t self:capability { dac_override dac_read_search kill sys_ptrace sys_nice };" >> bindadm.te;
echo "files_dontaudit_search_all_dirs(bindadm_t)" >> bindadm.te;
echo "files_manage_generic_locks(bindadm_t) >> bindadm.te;
echo "files_list_var(bindadm_t)" >> bindadm.te;
echo "selinux_get_enforce_mode(bindadm_t)" >> bindadm.te;
echo "seutil_domtrans_setfiles(bindadm_t)" >> bindadm.te;
echo "logging_send_syslog_msg(bindadm_t)" >> bindadm.te;
echo "userdom_dontaudit_search_user_home_dirs(bindadm_t)" >> bindadm.te;
Это основное содержимое для привилегированного дополнительного домена
пользователя. Исключена политика, специфичная для управления службой
Apache.
Теперь добавим политику, специфичную для управления службой Bind.
Можно позаимствовать эту политику из исходных текстов политики для
Bind. ак уже отмечалось, общая политика располагается в интерфейсных
файлах. Это значит, что если мы хотим включить общую политику,
относящуюся к Bind, можно посмотреть в соответствующем файле политики
bind.if (http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/bind.if)
если он доступен: Начиная со строки 252 в bind.if и
заканчивая строкой 305 описывается общая политика, разделяемая
модулем Bind для управления службой bind. Для включения этой политики
в наш Type Enforcement файл требуется всего лишь добавить вызов этого
интерфейса:
echo "bind_admin(bindadm_t, bindadm_r)" >> bindadm.te;
На этом Type Enforcement файл bindadm заканчивается. Далее необходимо
обеспечить другим доменам возможность взаимодействия с нашим доменом
bindadm_t. Реализуем эту часть политики, взяв за основу файл
webadm.if.
echo "## Bind administrator role" > bindadm.if;
echo "########################################" >> bindadm.if;
echo "## " >> bindadm.if;
echo "## Change to the bind administrator role." >> bindadm.if;
echo "## " >> bindadm.if;
echo '## ' >> bindadm.if;
echo "## " >> bindadm.if;
echo "## Role allowed access." >> bindadm.if;
echo "## " >> bindadm.if;
echo "## " >> bindadm.if;
echo "## " >> bindadm.if;
echo "#" >> bindadm.if;
echo "interface(\`bindadm_role_change',\`" >> bindadm.if;
echo " gen_require(\`" >> bindadm.if;
echo " role bindadm_r;" >> bindadm.if;
echo " ')" >> bindadm.if;
echo " allow \$1 bindadm_r;" >> bindadm.if;
echo "')" >> bindadm.if;
Позже общая политика администратора Bind (Bind Administrator Shared
policy) будет использоваться в нашем основном специально созданном
пользовательском домене SELinux. Следующим шагом будет создание
специализированного пользовательского домена SELinux для обслуживания
Bind, разрешающего данному домену осуществлять переход к роли
bindadm_r вызовом интерфейса bindadm_role_change. Создаваемый домен
SELinux будет основан на пользовательском домене staff_t, описание
политики смотрим в файле staff.te
echo "policy_module(bindguy, 0.0.1)" > bindguy.te;
echo "role bindguy_r;" >> bindguy.te;
echo "userdom_unpriv_user_template(bindguy)" >> bindguy.te;
echo "sudo_role_template(bindguy, bindguy_r, bindguy_t)" >> bindguy.te;
echo "ssh_role_template(bindguy, bindguy_r, bindguy_t)" >> bindguy.te;
echo "kernel_read_ring_buffer(bindguy_t)" >> bindguy.te;
echo "kernel_getattr_core_if(bindguy_t)" >> bindguy.te;
echo "kernel_getattr_message_if(bindguy_t)" >> bindguy.te;
echo "kernel_read_software_raid_state(bindguy_t)" >> bindguy.te;
echo "auth_domtrans_pam_console(bindguy_t)" >> bindguy.te;
echo "libs_manage_shared_libs(bindguy_t)" >> bindguy.te;
echo "seutil_run_newrole(bindguy_t, bindguy_r)" >> bindguy.te;
echo "netutils_run_ping(bindguy_t, bindguy_r)" >> bindguy.te;
echo "domain_read_all_domains_state(bindguy_t)" >> bindguy.te;
echo "domain_getattr_all_domains(bindguy_t)" >> bindguy.te;
echo "domain_obj_id_change_exemption(bindguy_t)" >> bindguy.te;
echo "files_read_kernel_modules(bindguy_t)" >> bindguy.te;
echo "kernel_read_fs_sysctls(bindguy_t)" >> bindguy.te;
echo "modutils_read_module_config(bindguy_t)" >> bindguy.te;
echo "modutils_read_module_deps(bindguy_t)" >> bindguy.te;
echo "miscfiles_read_hwdata(bindguy_t)" >> bindguy.te;
echo "term_use_unallocated_ttys(bindguy_t)" >> bindguy.te;
Чтобы разрешенить домену bindguy_t осуществлять переход в
ограниченное окружение SELinux bindadm_t, добавим вызов интерфейса
bindadm_role_change, определенного в нашем интерфейсном файле
bindadm.if:
echo "bindadm_role_change(bindguy_r)" >> bindguy.te;
Можно также автоматически создать сопоставление пользователя SELinux
с именем bindguy_u ролям bindguy_r, bindadm_r и system_r. Роль
system_r включается, чтобы bindadm_t мог останавить, запустить и
перезапустить системную службу bind.
echo "gen_user(bindguy_u, user, bindguy_r system_r bindadm_r, s0, s0 - mls_systemhigh, mcs_allcats)" >> bindguy.te;
Чтобы программы входа знали, что bindguy допустимый пользователь,
добавим контексты по умолчанию для этого пользователя, взяв за основу
контексты по умолчанию пользователя staff_u:
cp /etc/selinux/targeted/contexts/users/staff_u /etc/selinux/targeted/contexts/users/bindguy_u
sed -i 's/staff/bindguy/g' /etc/selinux/targeted/contexts/users/bindguy_u
Теперь можно собрать и установить обе политики bindguy и bindadm:
make -f /usr/share/selinux/devel/Makefile
sudo semodule -i bindguy.pp bindadm.pp
Далее командой useradd, опцией -Z и параметром bindguy_u можно
создать нового пользователя Linux:
sudo useradd -Z bindguy_u bindguy
Для того, чтобы разрешить пользователю bindguy использовать команду
sudo для автоматического перехода к Linux пользователю root и SELinux
домену bindadm_t, добавим в /etc/sudoers:
echo "bindguy ALL=(ALL) ROLE=bindadm_r TYPE=bindadm_t ALL" >> /etc/sudoers;
При входе пользователя bindguy в систему он оказывается в
пользовательском домене bindguy_t, основанном на домене staff_t.
Домен bindguy_t может осуществлять переход в домен bindadm_t,
используемый с правами root и позволяющий управлять службой Bind.
Например, выполнив следующую команду, пользователь bindguy сможет
перезапустить службу bind:
sudo service named restart
Также пользователю bindguy разрешается редактировать различные
конфигурационные и файлы информационного наполнения Bind. При этом,
например, пользователь bindguy не имеет прав изменить пароль
пользователя root.
Примечание: Если вы нашли какие-то ошибки в этом упражнении или у вас
есть какие-то вопросы или комментарии, пожалуйста свяжитесь с
автором. Спасибо!
Часть 7: su, newrole, sudo and run_init
Источник на английском: SELinux Lockdown Part Seven: su, newrole, sudo and run_init
Источник на русском: http://sapunidze.blogspot.com/2009/07/selinux-7-su-newrole-sudo-runinit.html
До выхода Fedora версии 9 пользователям, имеющим доступ к ролям, для
смены домена (Domain Transition) нужно было использовать команду
newrole. Команду можно установить с пакетом policycoreutils-newrole.
Например, пользователь запускал: newrole -r, и получал приглашение на
ввод его пароля. После чего команда newrole проверяла, что у
пользователя имеются все необходимые права доступа для осуществления
запрашиваемого доменного перехода, и разрешала или запрещала его.
При переходе в привилегированный пользовательский домен и желании
выполнить какое-то привилегированное задание пользователь выполнял
команду su, чтобы выполнить требования дискреционного контроля
доступа (Discretionary Access Control). Команда su запрашивает пароль
пользователя root.
В строгом окружении, чтобы получить права привилегированного
пользователя, придется запустить две программы и ввести два разных
пароля. При таком подходе для запуска любого привилегированного
задания пользователю потребуется доступ к паролю пользователя root.
Такому пользователю для запуска системной службы имеется другая
команда. Команда run_init осуществляет переход к домену сценариев
инициализации (Init Script), в котором, в свою очередь, в
соответствующем ей домене запускается системная служба. Эта программа
также запрашивает пароль.
Таким образом получается много команд и паролей всего лишь, например,
для перезапуска Apache.
В Fedora версии 9 для поддержки доменных переходов модифицировали
команду sudo. Рекомендуется вместо команд su и newrole использовать
sudo.
Два основных преимущества команды sudo заключаются в том, что данная
команда позволяет за одно действие сменить идентификатор (uid)
пользователя Linux и сменить домен SElinux, а также не требуется
вводить пароль пользователя root при условии, что ваш пользователь
добавлен в конфигурационный файл /etc/sudoers.
Целевой домен может быть указан опцией -t, целевая роль может быт
указана опцией -r. Также в файле конфигурации /etc/sudoers можно
настроить автоматическое переключение на определенные роль и домен по
умолчанию.
Пример: Linux пользователь joe входит в систему как SELinux
пользователь joe_u. SELinux пользователь joe_u имеет доступ к роли
joe_r, а также к ролям webadm_r и system_r. Роль joe_r сопоставлена
домену joe_t, который обладает всеми необходимыми полномочиями для
входа в систему ограниченного пользователя. Пользовательский домен
joe_t в соответствии с политикой имеет доступ к ролям system_r и
webadm_r. В файле /etc/sudoers о пользователе joe имеется следующая
запись:
joe ALL=(ALL) TYPE=webadm_t ROLE=webadm_r ALL
Эта запись разрешает при запуске команды sudo пользователем joe
осуществлять автоматическую смену значений параметров его контекста
SELinux, соответственно роли на webadm_r и типа на webadm_t.
При входе пользователя joe в систему он оказывается в домене joe_t.
Когда у Джо появляется необходимость запустить службу Apache он
просто запускает команду:
sudo service httpd start
Команда sudo изменяет идентификатор (uid) Джо на 0 и автоматически
осуществляет смену домена и роли Джо на определенные роль и домен -
webadm_r и webadm_t.
Джо также имеет доступ к роли system_r, необходимой для смены
пользовательского домена на домен сценария инициализации (Init
Script), который запускает httpd в правильном домене. Команда
run_init больше не требуется.
Если Джо доступно несколько ролей, он может переопределить роль и
домен, указанные в конфигурационном файле sudo, указав опции -r и -t
с требуемыми значениями роли и домена в качестве параметров.
Вывод:
Отдавайте предпочтение использованию команды sudo вместо команд su и
newrole.
Отдавайте предпочтение предоставлению доступа к роли system_r вместо
использования команды run_init.
Часть 8: Unconfined
Источник на английском: SELinux Lockdown Part Eight: Unconfined
Источник на русском: http://sapunidze.blogspot.com/2009/07/selinux-8-unconfined.html
Незакрытая (unconfined) область для процессов, которым требуется
практически неограниченный (unrestricted) доступ. Почти, потому что
не разрешается исполнение (execution) в перезаписываемых областях
памяти (writable memory). Для процессов, выполняющихся в незакрытой
области, если обратное не определено, ограничены следующие
полномочия: Execmem Execstack Execheap Execmod.
прим. перев.: в предыдущих частях термин "unconfined" переводился
как "неограниченный", тогда это было не столь принципиально, в этой
части близкие термины "(un)confined" и "(un)restricted"
встречаются чаще, дабы не превратить всё в масло масленое, для
первого термина здесь использую дословное значение.
В установленной по умолчанию Fedora 11 в незакрытом домене (Unconfined
Domain) выполняются следующие процессы: ядро Linux, RPM (пакетный
менеджер), init scripts (скрипты инициализации) и незакрытые
пользователи (unconfined users).
Если иное не определено, незакрытые процессы обычно запускают также
незакрытые программы. Предполагается, что незакрытые процессы
неограниченны и что потомки наследует это незакрытое окружение.
Исключения из этого правила, как было сказано, должны быть определены
путём создания политики, определяющей переходы из незакрытого домена в
ограниченные области при запуске программ незакрытым процессом.
Можно существенно повысить безопасность, удалив незакрытую область. В
результате все процессы будут ограниченны SELinux. В Fedora 11
незакрытую область разделили на две части. Первая часть - незакрытая
область для программ, вторая часть - незакрытая область для
пользователей. Вторую часть переименовали в <<unconfineduser domain>>.
Результат этого разделения позволяет удалить одно из двух или оба
окружения сразу. При удалении домена unconfined, являющегося доменом для
незакрытых программ, будут ограничены init-скрипты. В итоге системные
службы, для которых не определена политика SELinux, будут запускаться в
ограниченном окружении init-скрипта и не будут работать неограниченными.
Это отличный способ обеспечить отсутствие в системе неограниченных
системных служб. Процессы ядра и RPM останутся незакрытыми (unconfined),
потому что этим процессам для нормальной работы требуется слишком много
полномочий.
Для обеспечения работы всех операторов в ограниченном окружении можно
удалить домен unconfineduser. В случае принятия решения об удалении
домена unconfineduser необходимо соответствующим образом изменить
конфигурацию сопоставлений SELinux (SELinux mappings).
Если оператор уверенно владеет SELinux (feels comfortable with) не
должно быть причин, чтобы не удалить домен unconfined. При необходимости
он сможет реализовать политику SELinux для любого системного процесса,
не имеющего пока ещё своей политики.
Домен unconfineduser обычно удобнее сохранить, так как оператор имеет
возможность вручную определить, каким конкретно пользователям Linux
сопоставить этот домен. Настройками SELinux можно не разрешать
незакрытые входы в систему через OpenSSH или графический интерфейс
пользователя. Это означает, что пользователи имеющие доступ к домену
unconfineduser могут входить, используя это окружение, только на TTY
(терминал) или получать доступ к незакрытой области посредством команд
sudo или su вместе с newrole.
Использование незакрытого пользовательского домена в качестве
дополнительного домена повышает безопасность, только если не допускается
незакрытый вход в систему.
Пример:
Удалим домен unconfined, запретим вход незакрытых пользователей,
сопоставим роль unconfined_r существующему пользователю SELinux staff_u,
удалим пользователю SELinux staff_u роль sysadm_r. Добавим
Linux-пользователя John, сопоставим его SELinux-пользователю staff_u и
добавим для него запись в файл /etc/sudoers.
sudo setsebool -P unconfined_login off
sudo semanage user -m -L s0 -r s0-s0:c0.c1023 -R "staff_r system_r unconfined_r" -P user staff_u
sudo semodule -r unconfined
sudo useradd -Z staff_u john
sudo visudo (john ALL=(ALL) TYPE=unconfined_t ROLE=unconfined_r ALL)
John входит в систему как ограниченный SELinux-пользователь staff_u.
Когда John хочет получить привилегии пользователя root он просто
выполняет команду sudo. John может открыть оболочку пользователя root
(root shell) в незакрытой области, запустив команду sudo с опцией -s.
Такая конфигурация не должна сильно изменить ваши привычки (ways of
doing things), потому что не поощряется вход от имени пользователя root,
а ограниченный домен staff_t имеет все необходимые полномочия, требуемые
непривилегированному пользователю. Также можно создать собственный домен
пользователя, специально под ваши персональные требования и сопоставить
его роль специально созданным пользователям SELinux вместе с ролями
system_r и unconfined_r. Так вы сможете сохранить в оригинальном виде
SELinux-пользователя staff_u и изменять под ваши требования созданные
домен и пользователя SELinux.
Вывод:
Обдумайте удаление доменов Unconfined и Unconfineduser для повышения
безопасности.
Часть 9: Переключатели
Источник на английском: SELinux Lockdown Part Nine: Booleans
Источник на русском: http://sapunidze.blogspot.com/2009/07/selinux-9.html
Переключатели (booleans) это блоки политики, которые можно добавлять или
удалять на лету, переключая их значение. Старая примерная политика АНБ
(NSA) основывалась на модели минимальных привилегий. Это значит, что
разрешалось насколько возможно мало для успешного совершения задания.
Почти каждое правило, добавляемое в политику SELinux, добавляет новые
привилегии. Для максимального повышения безопасности, обеспечиваемой
SELinux, число активных правил следует минимизировать.
В Fedora версии 11 переключателями включены некоторые политики, которые
возможно в вашем случае не нужны. Рекомендуется удалять такие политики и
добавлять их только при необходимости.
Какие-то переключатели во включенном состоянии добавляют политики,
другие добавляют политики в выключенном состоянии. Простое описание
функциональности переключателя можно просмотреть командой: sudo semanage
boolean -l. Этих описаний обычно достаточно для понимания назначения
переключателя, хотя описания короткие. Если пропустить сообщение AVC:
denied (Access Vector Cache) через команду audit2why, можно узнать,
какой переключатель позволяет устранить эту проблему (если данная
проблема может быть решена установкой значения переключателя).
Иногда для понимания того, что разрешает переключатель, лучше посмотреть
его описание в исходном тексте политики, в которой он определен. Вам
необходимо иметь доступ к исходному тексту политики, а также знать, как
найти блоки политики, содержащие описание переключателя.
Существует три относительно старые утилиты, позволяющие просмотреть,
установить и переключить значение SELinux-переключателей: getsebool,
setsebool и togglesebool. В Fedora 11 функциональность этих утилит была
встроена в команду semanage: semanage boolean.
Имена переключателей должны указывать на модули с исходными текстами, в
которых определяются переключатели. К сожалению, часто бывает не так
просто найти определение переключателя в исходном тексте политики. В
лучшем случае название переключателя начинается с модуля, в котором он
определен.
Пример:
Как найти объявление и содержимое переключателя gpg_agent_env_file boolean
# semanage boolean -l | grep gpg
gpg_agent_env_file -> off Allow usage of the gpg-agent --write-env-file option.
This also allows gpg-agent to manage user files
Как следует из названия переключателя, он определяется где-то в модуле
gpg.te (в данном случае это строки с 196 по 203).
Данный переключатель, будучи включенным, позволяет программам,
работающим в SELinux-домене gpg_agent_t, записывать файлы в домашней
директории пользователя с обычным типом user_home_t.
Автор предполагает, что в блоке политики имеется ошибка, так как
gpg_agent_t может осуществить переход типа (type transition) только для
файлов user_home_t и не может для директорий.
Объявление этого переключателя, содержащее краткое описание
функциональности, можно найти на строках с 9 по 15.
Описать в рамках данной статьи все переключатели не представляется
возможным, поэтому было показано, как в общем случае найти объявление и
актуальное описание переключателя. При необходимости ограничения
переключателей, можно посмотреть добавляет он или удаляет политику при
включении и что фактически он делает. Кроме того, можно включить или
выключить переключатель, чтобы определить, нужна ли вам, реализованная
им политика. Также при необходимости можно <<скормить>> имеющиеся
сообщения AVC: denied утилите audit2why и посмотреть существуют ли
переключатели, позволяющие решить существующую проблему.
Далее рассматриваются некоторые переключатели.
unconfined_login
unconfined_login -> off Allow a user to login as an unconfined domain
Переключатель обсуждался в восьмой части этой серии. Если он установлен в
положение on (включен), тогда пользователи могут входить в систему в домене
unconfined_t. Можно сильно повысить безопасность установкой его в значение off
(выключено). Содержимое переключателя доступно в исходном файле политики
unconfineduser.te.
ssh_sysadm_login и xdm_sysadm_login
ssh_sysadm_login -> off Allow ssh logins as sysadm_r:sysadm_t
xdm_sysadm_login -> off Allow xdm logins as sysadm
Переключатель похож на unconfined_login, только имеет дело с доменом
sysadm_t. В настоящее время он НЕ работает. Поэтому пока не
рекомендуется сопоставлять любых пользователей SELinux роли sysadm_r.
Пользователи, имеющие доступ к этой роли, могут сразу входить в систему
в привилегированный домен.
*_allow_exec_content_t
allow_sysadm_exec_content -> off allow_sysadm_exec_content
allow_xguest_exec_content -> off allow_xguest_exec_content
allow_user_exec_content -> off allow_user_exec_content
allow_staff_exec_content -> off allow_staff_exec_content
allow_guest_exec_content -> off allow_guest_exec_content
Как видно описание этого переключателя не сильно полезно. Когда
переключатель включен пользователям, в соответствующем домене,
разрешается запускать их пользовательское содержимое в их собственном
окружении. Имеются в виду файлы с типами user_home_t, user_tmp_t или
если включены домашние директории nfs или samba типы nfs_t и cifs_t,
соответственно. Данные переключатели являются особенностью Fedora, их
содержимое можно найти в файле userdomain.if.
secure_module
secure_mode -> off Enabling secure mode disallows programs,
such as newrole, from transitioning to administrative user domains
Переключатель secure_mode можно включить для запрета переходов
пользовательских доменов в привилегированные домены. Переключатель
определяется в файле selinuxutil.te (строки с 289 по 295).
Пока переключатель работает только для команды newrole и НЕ работает для
команды sudo. Поэтому не поощряется рассчитывать на данный
переключатель.
secure_mode_insmod
secure_mode_insmod -> off Disable transitions to insmod
При включении данного переключателя для замкнутых (confined)
пользователей не разрешается осуществлять доменный переход к домену
insmod. Ограниченным пользовательским доменам будет запрещено загружать
модули ядра Linux. Переключатель определен в исходном файле modutils.te
(политика - строки 120-122, объявление переключателя - строки 4-6).
secure_mode_policyload
secure_mode_policyload -> off boolean to determine whether the system
permits loading policy, setting enforcing mode, and changing boolean values.
Set this to true and you have to reboot to set it back
Описание в принципе понятно. При включении переключателя исключается
политика, разрешающая загрузку других политик, изменять режим работы
SELinux и изменять значения переключателей. Политика описывается в
исходном файле selinux.te (строки с 44 по 52).
xserver_object_manager
xserver_object_manager -> off Support X userspace object manager
Данный переключатель оказывает достаточно сильный эффект. При его
включении становится доступным контроль доступа на уровне X сервера.
XACE (X Access Control Extension) позволяет оператору настраивать
взаимодействие процессов с X сервером. Политика по умолчанию всё ещё
имеет определенные шероховатости. XACE реализован для политики
безопасности SELinux, реализующей модель Multi Level Security,
ориентированной на обеспечение конфиденциальности. В целевой политике
(SELinux Targeted Policy) по умолчанию он выключен. Если вам хватает
смелости, включите его и опробуйте силу XACE.
После включения переключателя необходимо перезапустить X сервер.
Переключатель описан в файле с исходным текстом политики xserver.te
(строки с 749 по 766).
К сожалению, не всегда бывает легко найти, где определяются
переключатели. Есть куда стремиться в части именования переключателей.
Вывод:
Для большей безопасности минимизируйте объем политики.
Иногда включением переключателя политика добавляется, иногда политика
добавляется выключением переключателя. Описание переключателя можно
просмотреть в исходном тексте политики.
Часть 10: Заключение
Источник на английском: SELinux Lockdown Part Ten: Conclusion
Источник на русском: http://sapunidze.blogspot.com/2009/07/selinux-10.html
В предыдущих девяти частях было обсуждено много чего. Это последняя
статья в серии, в которой вкратце повторно перечисляются шаги,
позволяющие увеличить безопасность, обеспечиваемую SELinux. Подробности
по данным шагам доступны в предыдущих статьях.
1. Пользователь SELinux.
По умолчанию сопоставляйте пользователей Linux ограниченному
пользователю SELinux. Помните про принцип минимума полномочий. Например,
используйте пользователя guest_u:
sudo semanage login -m -s guest_u -r s0-s0 __default__
Если необходимо переопределить для новых Linux пользователей
пользователя SELinux по умолчанию можно воспользоваться командой useradd
и опцией -Z.
Не сопоставляйте пользователей Linux пользователю SELinux unconfined_u.
Исключением из этого правила может быть пользователь root. Пользователю
root должно разрешаться входить в систему только в экстренных случаях и
только через TTY.
2. PAM SEPermit.
Добавьте соответствующие записи для всех ваших ограниченных SELinux
пользователях в /etc/security/sepermit.conf, чтобы при работе SELinux в
разрешающем (permissive) режиме блокировать их попытки входа в систему .
Вы можете принять решение о создании уникального SELinux пользователя
для себя, освобожденного от ограничения SEPermit.
3. Permissive mode против Permissive Domains.
Всегда отдавайте предпочтение использованию разрешающих доменов
(Permissive Domains) вместо разрешающего режима (Permissive Mode).
4. Не изменяйте предустановленных по умолчанию пользователей SELinux.
Если вам требуется особенный пользователь SELinux и/или пользовательский
домен SELinux создайте новый, взяв за основу существующий.
5. Используйте управление доступом на основе ролей (Role based Access
control) для ограничения привилегий пользователей, в том числе
пользователя root.
6. Не изменяйте существующие роли / домены пользователей.
Если требуется специальная роль, создайте на основе существующей новую и
сопоставьте её новому пользователю SELinux. Вместе с тем вы можете
сопоставлять существующим ролям новых пользователей SELinux.
7. Используйте команду sudo, вместо su и newrole.
8. Удалите домен(ы) unconfined (неограниченный).
Обязательно сделайте sudo semodule -r unconfined, чтобы отключить
системные службы, не имеющие определенных политик. Используйте команду
sudo semodule -r unconfineduser, чтобы полностью отключить
неограниченную среду пользователя (не рекомендуется). Если вы решили
удалить unconfineduser, не забудьте соответствующим образом
перенастроить сопоставления пользователей SELinux, чтобы учесть это
изменение. Используйте вместо unconfined домен sysadm.
однако, автор отдаёт предпочтение домену unconfined против домена sysadm
в качестве дополнительного на все случаи привилегированного
пользовательского домена, потому что:
a. для запрета входа неограниченным (unconfined) пользователям можно установить
переключатель unconfined_login.
b. не работают переключатели ssh_sysadm_login и xdm_sysadm_login.
c. sysadm - это напившийся (кривой) unconfined.
d. вход пользователю root отключен.
e. домен unconfined используется только как дополнительный привилегированный домен,
доступный только при использовании sudo
e.1. за исключением пользователя root, который может входить только в экстренном
случае через TTY.
9. Удалите как можно больше политик включением и выключением
соответствующих переключателей.
установите unconfined_login в значение off
установите xserver_object_manager в значение on
установите *_exec_content в значение off
рассмотрите применение переключателей secure_mode_*
Хорошая статья.
Но selinux всё же дружественностью как не отличался, так и продолжает. Не знаю, для каких лунатиков он создан, но явно не для простых людей.
