newrole -r role_r -t domain_t (обычно существует только один домен, разрешенный для данной роли, параметр -t, таким образом, часто может быть исключен). Эта команда аутентифицирует вас, попросив ввести ваш пароль. Эта функция запрещает программам автоматически переключать роли. Такие изменения могут произойти только в том случае, если они прямо разрешены в политике SELinux.
ssh маркируется ssh_exec_t, и при запуске программы он автоматически переключается на ssh_t. Этот автоматический механизм перехода домена позволяет предоставлять только права, требуемые каждой программой. Это фундаментальный принцип SELinux.
apt install selinux-basics selinux-policy-default auditd автоматически установит пакеты, необходимые для настройки системы SELinux.
unconfined модуль (управление модулями подробно описано далее в этом разделе).
fixfiles relabel.
selinux=1 security=selinux в ядро Linux. Параметр audit=1 позволяет SELinux регистрировать все запрещаемые операции. Наконец, параметр enforcing=1 приводит правила в действие: без него SELinux работает в режиме по умолчанию permissive, в котором запрещаемые действия регистрируются, но всё же выполняются. Таким образом, вы должны изменить файл конфигурации загрузки GRUB для добавления желаемых параметров. Один из простых способов сделать это - изменить GRUB_CMDLINE_LINUX переменную в /etc/default/grub и запустить update-grub. SELinux будет активен после перезагрузки.
selinux-activate автоматизирует эти операции и заставляет маркировку на следующем загрузке (который избегает новых немаркированных файлов, созданных в то время когда SELinux ещё не был активизирован, но маркировка ещё продолжалась).
semodule. Кроме того, вы должны быть в состоянии определить роли, которые каждый пользователь может одобрить, и это может быть сделано командой semanage.
/etc/selinux/default/. В отличие от других файлов конфигурации, которые вы можете найти в /etc/, все эти файлы не должны быть изменены вручную. Вы должны использовать программы, предназначенные для этой цели.
/usr/share/selinux/default/. Чтобы включить один из этих модулей в текущую конфигурацию, следует использовать semodule -i module.pp.bz2. Расширение pp.bz2 означает policy package (сжатый bzip2).
semodule -r module. Наконец, команда semodule -l перечисляет модули, которые в настоящее время установлены. Она также выводит их номера версий. Модули могут быть выборочно включены с semodule -e и отключены командой semodule -d.
#semodule -i /usr/share/selinux/default/abrt.pp.bz2libsemanage.semanage_direct_install_info: abrt module will be disabled after install as there is a disabled instance of this module present in the system. #semodule -laccountsd acct [...]#semodule -e abrt#semodule -d accountsd#semodule -labrt acct [...]#semodule -r abrtlibsemanage.semanage_direct_remove_key: abrt module at priority 100 is now active.
semodule сразу загружает новую конфигурацию, если вы не используете её -n. Стоит отметить, что программа действует по умолчанию в текущей конфигурации (на которую указывает переменная SELINUXTYPE в /etc/selinux/config), но вы можете изменить другую, указав её опцией -s.
semanage.
-a add - добавить, -d delete - удалить, -m modify - изменить, -l list - список, и -t type - тип, чтобы указать тип (или домен).
semanage login -l перечисляет текущее отображение между идентификаторами пользователя и идентификаторами SELinux. Пользователи, которые не имеют явной записи, получают идентификатор, указанный в записи __default__. Команда semanage login -a -s user_u user свяжет user_u идентификатор с данным пользователем. Наконец, semanage login -d user сбросит запись сопоставления, назначенную этому пользователю.
#semanage login -a -s user_u rhertzog#semanage login -lLogin Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * rhertzog user_u s0 * root unconfined_u s0-s0:c0.c1023 * #semanage login -d rhertzog
semanage user -l перечисляет сопоставление между пользовательскими идентификаторами SELinux и допустимыми ролями. Чтобы добавить новый идентификатор требуется определить как соответствующие роли, так и префикс маркировки, который используется для присвоения типа личным файлам (/home/user/*). Префикс должен быть выбран среди user, staff и sysadm. Префикс “staff” приводит в файлы типа “staff_home_dir_t”. Создание нового пользовательского идентификатора SELinux осуществляется с semanage user -a -Rroles -P prefix identity . Наконец, вы можете удалить пользовательский идентификатор SELinux командой semanage user -d identity.
#semanage user -a -R 'staff_r user_r' -P staff test_u#semanage user -lLabeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm s0 s0-s0:c0.c1023 staff_r sysadm_r system_r staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r test_u staff s0 s0 staff_r user_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r #semanage user -d test_u
/srv/www/, вы могли бы выполнить semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?", за которым следует restorecon -R/srv/www/. Прежняя команда регистрирует новые правила маркировки, а последняя восстанавливает типы файлов в соответствии с действующими правилами маркировки.
semanage port -m -t http_port_t -p tcp 8080.
getsebool утилита может быть использована для проверки этих опций (getsebool boolean отображает один вариант, и getsebool -a отображает все. setsebool boolean value изменяет текущее значение опции Boolean. -P делает изменение постоянным, это означает, что новое значение становится по умолчанию и будет храниться между перезагрузками. Нижеприведенный пример предоставляет веб-серверам доступ к домашним каталогам (это полезно, когда пользователи имеют личные веб-сайты в ~/public_html/.
#getsebool httpd_enable_homedirshttpd_enable_homedirs --> off #setsebool -P httpd_enable_homedirs on#getsebool httpd_enable_homedirshttpd_enable_homedirs --> on
/usr/share/doc/selinux-policy-doc/html/) и выборочных файлов, которые могут быть использованы в качестве шаблонов для создания новых модулей. Установите эти файлы и более внимательно изучите их:
$cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile$cp /usr/share/doc/selinux-policy-doc/example.fc ./$cp /usr/share/doc/selinux-policy-doc/example.if ./$cp /usr/share/doc/selinux-policy-doc/example.te ./
.te является самым важным. Он определяет правила. .fc файл определяет “file contexts”, то есть типы, назначенные для файлов, относящихся к этому модулю. Данные в файле .fc используются во время этапа маркировки файла. Наконец, файл .if определяет интерфейс модуля: это набор “public functions”, которые другие модули могут использовать для правильного взаимодействия с модулем, который вы создаёте.
myapp_domtrans”) контролирует, кто может выполнить приложение. Второй (“myapp_read_log”) предоставляет права чтения в файлах журнала приложения.
.te. Таким образом, вы должны объявить все типы, которые вы используете (с макросом gen_require ), и использовать стандартные директивы для предоставления прав. Обратите внимание, что вы можете использовать интерфейсы, предоставляемые другими модулями. Следующий раздел даст больше объяснений о том, как выразить эти права.
Пример 14.3. example.if File
## <summary>Myapp example policy</summary>
## <desc>
## <p>
## More descriptive text about myapp. The desc
## tag can also use p, ul, and ol
## html tags for formatting.
## </p>
## <p>
## This policy supports the following myapp features:
## <ul>
## <li>Feature A</li>
## <li>Feature B</li>
## <li>Feature C</li>
## </ul>
## </p>
## </desc>
#
########################################
## <summary>
## Execute a domain transition to run myapp.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to transition.
## </summary>
## </param>
#
interface(`myapp_domtrans',`
gen_require(`
type myapp_t, myapp_exec_t;
')
domtrans_pattern($1,myapp_exec_t,myapp_t)
')
########################################
## <summary>
## Read myapp log files.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to read the log files.
## </summary>
## </param>
#
interface(`myapp_read_log',`
gen_require(`
type myapp_log_t;
')
logging_search_logs($1)
allow $1 myapp_log_t:file read_file_perms;
')
example.te:
policy_module(example,1.0.0)# a non-base module name must match the file name ######################################## # # Declarations # type myapp_t;
type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t)
type myapp_log_t; logging_log_file(myapp_log_t)
type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Myapp local policy # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms };
allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)
|
Модуль должен быть идентифицирован по его названию и номеру версии. Эта директива необходима.
|
|
Если модуль вводит новые типы, он должен объявлять их такими директивами, как эта. Не стесняйтесь создавать столько типов, сколько требуется, а не предоставлять слишком много бесполезных прав.
|
|
Эти интерфейсы определяют тип myapp_t как технологический домен, который должен использоваться любым исполняемым маркированным myapp_exec_t. Подразумевается, что это добавляет атрибут exec_type на эти объекты, что, в свою очередь, позволяет другим модулям предоставлять права на выполнение этих программ: например, userdomain модуль user_t, staff_t, и sysadm_t для их выполнения. Домены других ограниченных приложений не будут иметь права на их выполнение, если только правила не предоставляют им аналогичные права (это случай, например, dpkg с его доменом dpkg_t.
|
| logging_log_file - это интерфейс, предоставляемый ссылочной политикой. Это указывает на то, что файлы, отмеченные данным типом, являются лог-файлами, которые должны извлечь выгоду из связанных правил (например, предоставление прав на logrotate, чтобы мочь ими манипулировать).
|
|
Директива allow является базовой директивой, используемой для разрешения операции. Первым параметром является домен процесса, который позволяет выполнять операцию. Второй определяет объект, которым может манипулировать процесс прежнего домена. Этот параметр имеет форму “type:class“, где type является его типом SELinux и class описывает природу объекта (файл, каталог, сокет, fifo и т.д.). Наконец, последний параметр описывает разрешения (разрешённые операции).
Разрешения определяются как набор разрешенных операций и следуют этому шаблону: { operation1 operation2 }. Тем не менее, вы также можете использовать макросы, представляющие самые полезные разрешения. /usr/share/selinux/devel/include/support/obj_perm_sets.spt перечисляет их.
Следующая веб-страница предоставляет относительно исчерпывающий список классов объектов и разрешений, которые могут быть предоставлены.
|
avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1Таблица 14.1. Анализ трассировки SELinux
| Сообщение | Описание |
|---|---|
avc: denied | Операция была отклонена. |
{ read write } | Эта операция требовала read и write разрешения. |
pid=1876 | Процесс с PID 1876 выполнил операцию (или попытался её выполнить). |
comm="syslogd" | Процесс был экземпляром программы syslogd. |
name="xconsole" | Целевой объект был назван xconsole. Иногда вы также можете иметь переменную “path” с полным путём вместо этого. |
dev=tmpfs | Устройство, в котором размещён целевой объект, это tmpfs (файловая система в памяти). На реальном диске можно увидеть раздел, хостящий объект (например, “sda3”). |
ino=5510 | Объект идентифицируется номером inode 5510. |
scontext=system_u:system_r:syslogd_t:s0 | Это контекст безопасности процесса, который выполнил операцию. |
tcontext=system_u:object_r:device_t:s0 | Это контекст безопасности целевого объекта. |
tclass=fifo_file | Целевой объект - это файл FIFO. |
allow syslogd_t device_t:fifo_file { read write }. Этот процесс может быть автоматизирован, и это именно то, что предлагает команда audit2allow в пакете (policycoreutils). Этот подход полезен только в том случае, если различные объекты уже правильно обозначены в соответствии с тем, что должно быть ограничено. В любом случае, вам придется тщательно пересмотреть сгенерированные правила и проверить их в соответствии с вашими знаниями о приложении. Фактически, такой подход имеет тенденцию предоставлять больше прав, чем это действительно необходимо. Надлежащее решение часто заключается в создании новых типов и предоставлении прав только на эти типы. Также случается, что отказ в операции не является фатальным для приложения, в этом случае может быть лучше просто добавить правило “dontaudit”, чтобы избежать записи в журнал, несмотря на эффективный отказ.
example.if, example.fc, и example.te) будут соответствовать вашим ожиданиям по новым правилам, переименуйте их в myapp.extension и запустите make NAME=devel для создания модуля в файле myapp.pp вы можете сразу же загрузить его semodule -i myapp.pp). Если несколько модулей определены, make создаст все соответствующие файлы .pp.