3.3.7.2.2 Роли пользователей
Скачать документ Роль sysadm - администратор системы
Роль — пользователь системы
В ОС пользователи по умолчанию сопоставляются SELinux-пользователю <unconfined_u>. SELinux-пользователь <unconfined_u>, в свою очередь, сопоставлен ролям <unconfined_r> и <system_r>.
Обе роли <unconfined_r> и <system_r> сопоставляются доменам безопасности SELinux. Домены безопасности SELinux - это определённые окружения безопасности для процессов.
Неограниченный домен безопасности <unconfined_t> - зарезервированное окружение для процессов, которые в значительной степени освобождены от ограничений SELinux. Роль <system_r> сопоставляется доменам безопасности для системных процессов.
SELinux-пользователь <unconfined_u> имеет доступ к роли <system_r>, чтобы иметь возможность запускать системные процессы в своих доменах безопасности. SELinux-пользователь <unconfined_u> работает в домене безопасности <unconfined_t> через роль <unconfined_r>, которой он сопоставлен.
Команда «semanage» позволяет добавлять, изменять и удалять сопоставления между ОС- и SELinux-пользователями, так же как и другие настройки, касающиеся управления SELinux.
Чтобы с помощью команды «semanage» посмотреть какому SELinux- пользователю по умолчанию сопоставлены пользователи ОС, наберите:
semanage login -l | grep default
В примере выше пользователи по умолчанию сопоставлены SELinux- пользователю <unconfined_u>.
Чтобы изменить это и сопоставить пользователей по умолчанию ограниченному SELinux-пользователю с именем <user_u>, просто наберите:
semanage login -m -s user_u "__default__"
В результате все новые пользователи будут по умолчанию сопоставляться ограниченному SELinux-пользователю <user_u>.
Вы можете переопределить данное сопоставление при добавлении пользователей командой «useradd» используя опцию «-Z». Эта опция определяет, какому SELinux-пользователю должен быть сопоставлен пользователь ОС.
Например, наберите:
useradd -Z guest_u joe
В результате будет создан новый пользователь с именем joe, который будет сопоставлен SELinux-пользователю <guest_u>, вместо определённого по умолчанию SELinux-пользователя.
Также для изменения сопоставления между пользователем и SELinux-пользователем может быть использована команда «usermod» с опцией «-Z».
Существует несколько предопределённых профилей SELinux-пользователей. Список данных профилей можно вывести командой «semanage», наберите:
semanage user -l
SELinux-пользователь <unconfined_u> - это среда, в которой по умолчанию работают все пользователи. Этот пользователь в значительной степени освобождён от ограничений, накладываемых SELinux. Если Вы хотите повысить безопасность вашей системы, тогда не следует сопоставлять реальных пользователей, не пользователя root, SELinux-пользователю <unconfined_u>.
Вход пользователя root должен быть запрещён. Root должен иметь возможность войти с терминала только в случае крайней необходимости. Чтобы повысить безопасность использования root, можно сопоставить пользователя root SELinux-пользователю <sysadm_u>.
Ролевой доступ SELinux используется для обеспечения возможности назначения нескольких ограниченных окружений SELinux одному SELinux-пользователю.
В SELinux роли пользователя (User Roles) - это домены пользователя или пользовательские домены (User Domains). Когда упоминаются роли, часто имеется в виду дополнительный (secondary) пользовательский домен пользователя SELinux. Часто роли, предназначенные для использования в качестве дополнительных доменов пользователя, отличаются от основных (primary) доменов. Это объясняется тем, что пользователи ОС фактически не используют для входа в систему роли, созданные как дополнительные домены пользователя. Вместо этого пользователи Linux, используя команду «sudo» или комбинацию команд «su» и «newrole», осуществляют переключение домена или доменный переход (Domain Transition) к их дополнительной роли.
Роль sysadm - администратор системы
Пример роли, предназначенной для использования в качестве основного домена пользователя. SELinux пользователь <sysadm_u> сопоставлен роли <sysadm_r>. Это сопоставление можно увидеть, выполнив команду:
semanage user -l | grep sysadm_u
По умолчанию пользователи ОС, сопоставленные пользователю 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> в качестве его основного домена пользователя.
Роль <user_r> — пользователь системы
Пользовательский домен, используемый только в качестве основного. Описание пользователя SELinux <user_u> приведено ранее.
Какие-то домены пользователей могут использоваться пользователями для входа в систему, потому что эти домены, например, имеют полномочия по доступу к домашней директории пользователя. Такие домены в предыдущей части назывались основными (primary) пользовательскими доменами. Другие домены созданы в качестве дополнительных. Пользователи, используя команды «sudo» или «su» вместе с «newrole», могут осуществить доменный переход (Domain Transition) к этим дополнительным доменам.
Дополнительные домены не могут использоваться для входа в систему. Далее будет продемонстрировано как создаётся такой дополнительный пользовательский домен. Целью является реализовать привилегированную роль SELinux, которой предоставлены полномочия по управлению DNS службой Bind.
Начнём с создания нового дополнительного домена пользователя с названием «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. Для включения этой политики в наш 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 semodule -i bindguy.pp bindadm.pp
Далее командой «useradd», опцией «-Z» и параметром <bindguy_u> можно создать нового пользователя Linux:
useradd -Z bindguy_u bindguy
Для того чтобы разрешить пользователю bindguy использовать команду «sudo» для автоматического перехода к пользователю 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:
systemctl restart named
Также пользователю bindguy разрешается редактировать различные конфигурационные файлы и файлы информационного наполнения Bind. При этом, например, пользователь bindguy не имеет прав изменить пароль пользователя root.
Подведём итог. Процессы и файлы маркируются метками - контекстом SELinux, который содержит информацию: пользователь SELinux, роль, тип и уровень (опционально). Когда SELinux включён, вся эта информация используется для принятия решения о предоставлении доступа.
В контексте SELinux используется следующий синтаксис SELinux:
<user>:<role>:<type>:<level>:<пользователь_SELinux>
<Пользователь_SELinux> - это сущность, определённая в политике, которая отвечает за определённый набор ролей и за определённый набор MLS-уровней. Каждый пользователь ОС сопоставлен пользователю SELinux посредством политики SELinux. Это позволяет пользователям наследовать ограничения, установленные на пользователей SELinux. Сопоставленные сущности пользователей SELinux используются в контексте SELinux для процессов в сессии, в порядке определения, для каких ролей и уровней они применимы.
Роль - это часть модели безопасности Ролевого управления доступом Role-Based Access Control (RBAC). Роль - это атрибут RBAC. Пользователи SELinux авторитетны для ролей, а роль авторитетна для доменов. Каждая конкретная роль определяет, какие домены могут быть доступны для пользователей с этой ролью. Роль служит промежуточным звеном между доменами и пользователями SELinux. Роль, которой обладает пользователь, определяет, в какие домены может попасть пользователь - фактически, этот механизм управляет доступностью объектов. Таким образом, уменьшается риск, связанный с уязвимостью повышения привилегий в системе. По умолчанию пользователям назначена неопределённая роль, не накладывающая ограничений на пользователя. Но есть и предопределённые роли пользователя и администратора системы, которые могут быть назначены администратором для повышения безопасности системы.
Тип - это атрибут Type Enforcement. Тип определяет домен для процессов и тип для файлов. Правила политики SELinux определяют, как типы взаимодействуют друг с другом, является ли тип доменом, получающим доступ к типу, или доменом, получающим доступ к другому домену. Доступ разрешается, только если существует определённое правило политики SELinux, позволяющее данное действие.
Контекст безопасности записывается в атрибуты файла (в файловой системе) и создаётся при установке SELinux (операция labeling). Уже присвоенный контекст безопасности может быть впоследствии изменён - операцией «transition».
Дата последнего изменения: 07.10.2024
Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.