russian fedora summit

...иными словами своеобразный конгресс русских общин

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

фотоаппарата как водится в таких случаях ни у кого не оказалось, но не запечатлить момент для истории было нельзя. на фото слева направо (если я ничего не напутал) - Alexander Tiurin, Peter Lemenkov, Alexey Torkhov, Alexey Vasyukov, Inna Kabanova, Viacheslav Kaloshin. я - с другой стороны телефона (этим и определяется качество и размер)

SELinux Lockdown, 10: Заключение

оригинал - SELinux Lockdown Part Ten: Conclusion

Завершение цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

В предыдущих девяти частях было обсуждено много чего. Это последняя статья в серии, в которой вкратце повторно перечисляются шаги, позволяющие увеличить безопасность, обеспечиваемую 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 Lockdown, 9: Переключатели

оригинал - SELinux Lockdown Part Nine: Booleans

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

Переключатели (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).

К сожалению, не всегда бывает легко найти, где определяются переключатели. Есть куда стремиться в части именования переключателей.

Вывод:
Для большей безопасности минимизируйте объем политики.
Иногда включением переключателя политика добавляется, иногда политика добавляется выключением переключателя.
Описание переключателя можно просмотреть в исходном тексте политики.

Справка: man getsebool, man setsebool, man togglesebool, man audit2why, man semanage

SELinux Lockdown, 8: Unconfined

оригинал - SELinux Lockdown Part Eight: Unconfined

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

Незакрытая (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 для повышения безопасности.

Справка: man semanage, man semodule, man visudo, man setsebool, man sudo

SELinux Lockdown, 7: su, newrole, sudo и run_init

оригинал - SELinux Lockdown Part Seven: su, newrole, sudo and run_init

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

До выхода 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.

Справка: man su, man sudo, man newrole, man run_init

SELinux Lockdown, 6: Создание ролей SELinux

оригинал - SELinux Lockdown Part Six: Customized SELinux Roles

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

В четвёртой части серии описывался процесс создания пользовательских доменов 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 если он доступен:

Начиная со строки 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.

Примечание: Если вы нашли какие-то ошибки в этом упражнении или у вас есть какие-то вопросы или комментарии, пожалуйста свяжитесь с автором. Спасибо!

Справка: man bind, man semodule, man sudo, man useradd

SELinux Lockdown, 5: SELinux RBAC

оригинал - SELinux Lockdown Part Five: SELinux RBAC

Продолжаю выкладывать перевод цикла статей по использованию SELinux. Оригинал на английском языке опубликован в блоге Доминика Грифта (Dominick Grift).

В первой главе этой серии рассказывалось, что пользователи 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/sysadm_r@localhost.localdomain.tld

Также роль 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).

Справка: man newrole, man su, man sudo, man semanage