Управление SELinux в RHEL: настройка и устранение неполадок

Введение

В этой лабораторной работе вы получите практический опыт управления безопасностью SELinux в RHEL. Вы научитесь изменять режимы принудительного применения SELinux (SELinux enforcement modes), как временно, так и постоянно, а также настраивать Apache с пользовательскими контекстами файлов SELinux. Лабораторная работа также охватывает настройку политики SELinux для домашних каталогов пользователей с использованием булевых переменных (booleans) и предоставляет практические шаги по устранению неполадок и разрешению отказов SELinux для веб-серверов Apache и пользовательского веб-контента.

Изменение режима принудительного применения SELinux

На этом шаге вы узнаете, как управлять режимами SELinux, как временно, так и постоянно. SELinux (Security-Enhanced Linux) — это механизм безопасности, обеспечивающий обязательный контроль доступа (MAC) для ядра Linux. Он определяет права доступа для процессов, файлов и других системных ресурсов.

SELinux работает в трех основных режимах:

Enforcing (Принудительный): Политика SELinux применяется. Доступы, запрещенные политикой, блокируются и регистрируются. Это режим по умолчанию и самый безопасный режим.
Permissive (Разрешающий): Политика SELinux не применяется. Доступы, запрещенные политикой, регистрируются, но не блокируются. Этот режим полезен для устранения неполадок и тестирования новых политик.
Disabled (Отключен): SELinux отключен. Политика не загружена и не применяется. Этот режим обычно не рекомендуется для производственных систем.

Вы потренируетесь изменять режим SELinux с помощью инструментов командной строки и путем изменения файлов конфигурации.

Сначала давайте проверим текущий режим принудительного применения SELinux.

Проверьте текущий режим принудительного применения SELinux.

Вы можете использовать команду getenforce, чтобы быстро увидеть текущий режим SELinux.
```
getenforce
```
Вы должны увидеть Enforcing (Принудительный) в качестве вывода, что указывает на то, что SELinux в настоящее время применяет свои политики.
```
Enforcing
```
Временно измените режим SELinux на permissive (разрешающий).

Команда setenforce позволяет изменять режим SELinux во время выполнения. Значение 0 устанавливает режим в permissive (разрешающий), а 1 устанавливает его в enforcing (принудительный). Это изменение является временным и не сохранится после перезагрузки.
```
sudo setenforce 0
```
Теперь проверьте изменение, снова используя getenforce.
```
getenforce
```
Вывод теперь должен быть Permissive (Разрешающий).
```
Permissive
```
Временно измените режим SELinux обратно на enforcing (принудительный).

Чтобы отменить временное изменение, используйте setenforce 1.
```
sudo setenforce 1
```
Проверьте режим еще раз.
```
getenforce
```
Вывод должен снова быть Enforcing (Принудительный).
```
Enforcing
```
Постоянно измените режим SELinux по умолчанию на permissive (разрешающий).

Чтобы изменения режима SELinux сохранялись после перезагрузки, вам необходимо изменить файл /etc/selinux/config. Этот файл определяет режим SELinux по умолчанию для системы.

Откройте файл конфигурации с помощью nano.
```
sudo nano /etc/selinux/config
```
Внутри редактора nano найдите строку, начинающуюся с SELINUX=, и измените ее значение с enforcing (принудительный) на permissive (разрешающий).
```
## This file controls the state of SELinux on the system.
## SELINUX= can take one of these three values:
##     enforcing - SELinux security policy is enforced.
##     permissive - SELinux prints warnings instead of enforcing.
##     disabled - No SELinux policy is loaded.
SELINUX=permissive
## SELINUXTYPE= can take one of these three values:
##     targeted - Targeted processes are protected,
##                for the majority of users.
##     minimum - Modification of targeted policy
##               uses current settings and adds to it.
##     mls - Multi Level Security protection.
SELINUXTYPE=targeted
```
Нажмите Ctrl+X, чтобы выйти, затем Y, чтобы подтвердить сохранение, и Enter, чтобы записать в тот же файл.

После сохранения файла вы можете подтвердить изменение в файле конфигурации с помощью grep.
```
grep '^SELINUX' /etc/selinux/config
```
Вывод должен показать SELINUX=permissive.
```
SELINUX=permissive
SELINUXTYPE=targeted
```
Важное примечание: Изменение /etc/selinux/config не сразу изменяет активный режим SELinux. Он только устанавливает режим, который будет применен после следующей перезагрузки системы. Чтобы увидеть текущий активный режим, вам все равно нужно использовать getenforce.
```
getenforce
```
Он все равно должен показывать Enforcing (Принудительный), потому что система еще не была перезагружена.
```
Enforcing
```
Измените режим SELinux по умолчанию обратно на enforcing (принудительный) в файле конфигурации.

Теперь давайте изменим постоянный режим обратно на enforcing (принудительный). Это рекомендуемая и наиболее безопасная настройка для SELinux.

Откройте файл конфигурации снова.
```
sudo nano /etc/selinux/config
```
Измените параметр SELINUX= обратно на enforcing (принудительный).
```
## This file controls the state of SELinux on the system.
## SELINUX= can take one of these three values:
##     enforcing - SELinux security policy is enforced.
##     permissive - SELinux prints warnings instead of enforcing.
##     disabled - No SELinux policy is loaded.
SELINUX=enforcing
## SELINUXTYPE= can take one of these three values:
##     targeted - Targeted processes are protected,
##                for the majority of users.
##     minimum - Modification of targeted policy
##               uses current settings and adds to it.
##     mls - Multi Level Security protection.
SELINUXTYPE=targeted
```
Сохраните и выйдите из файла (Ctrl+X, Y, Enter).

Подтвердите изменение в файле конфигурации.
```
grep '^SELINUX' /etc/selinux/config
```
Вывод теперь должен показывать SELINUX=enforcing.
```
SELINUX=enforcing
SELINUXTYPE=targeted
```
На данный момент активный режим SELinux системы все еще Enforcing (Принудительный) (если вы не перезагрузили систему после шага 4), и постоянная настройка также Enforcing (Принудительный).

Настройка Apache с пользовательскими контекстами файлов SELinux

На этом шаге вы узнаете, как настроить Apache для обслуживания веб-контента из нестандартного каталога и управлять его контекстами файлов SELinux. По умолчанию политики SELinux ограничивают Apache (httpd) обслуживанием файлов только из определенных каталогов, в основном /var/www/html. Если вы поместите веб-контент в другое место, SELinux не позволит Apache получить к нему доступ, даже если разрешения файловой системы верны. Именно здесь вступают в игру контексты файлов SELinux.

Контекст файла SELinux — это метка, применяемая к файлу или каталогу, которая определяет его атрибуты безопасности. Чтобы Apache обслуживал контент из пользовательского местоположения, это местоположение и его содержимое должны иметь правильный контекст SELinux, обычно httpd_sys_content_t. Вы будете использовать semanage fcontext для определения постоянного правила и restorecon для его применения.

Сначала вам нужно установить веб-сервер Apache HTTP.

Установите веб-сервер Apache HTTP.

Используйте менеджер пакетов dnf для установки пакета httpd.
```
sudo dnf install -y httpd
```
Вы должны увидеть вывод, указывающий на успешную установку пакета httpd и его зависимостей.
Создайте пользовательский каталог для веб-контента и файл index.html.

Вы создадите новый каталог с именем /custom и поместите в него простой файл index.html. Это будет ваш нестандартный корневой каталог веб-документов.
```
sudo mkdir /custom
echo 'This is custom web content.' | sudo tee /custom/index.html
```
Проверьте содержимое файла index.html.
```
cat /custom/index.html
```
```
This is custom web content.
```
Настройте Apache для использования нового корневого каталога документов.

Основной файл конфигурации Apache — /etc/httpd/conf/httpd.conf. Вам нужно отредактировать этот файл, чтобы указать Apache на ваш новый каталог /custom вместо каталога по умолчанию /var/www/html.

Откройте файл конфигурации с помощью nano.
```
sudo nano /etc/httpd/conf/httpd.conf
```
Внутри редактора найдите строки DocumentRoot "/var/www/html" и <Directory "/var/www/html">. Измените оба вхождения /var/www/html на /custom.

Соответствующие разделы должны выглядеть следующим образом после изменения:
```
#
## DocumentRoot: The directory out of which you will serve your
## documents. By default, all requests are taken from this directory, but
## symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/custom"

#
## Relax access to content within /var/www.
#
<Directory "/custom">
    AllowOverride None
    ## Allow open access:
    Require all granted
</Directory>
```
Сохраните и выйдите из файла (Ctrl+X, Y, Enter).
Запустите и включите веб-службу Apache.

После изменения конфигурации вам необходимо запустить службу httpd. Поскольку вы находитесь в среде контейнера, systemctl недоступен. Вы запустите httpd напрямую.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
Символ & запускает команду в фоновом режиме, позволяя вам продолжать использовать терминал. Вы должны увидеть вывод, аналогичный этому, указывающий на запуск Apache.
```
[1] 5094
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80::216:3eff:fe00:63b%eth0. Set the 'ServerName' directive globally to suppress this message
```
Примечание: Предупреждающее сообщение о полном доменном имени сервера является нормальным в этой лабораторной среде, и его можно спокойно игнорировать.

Чтобы убедиться, что Apache работает, вы можете проверить наличие процесса httpd.
```
ps aux | grep httpd
```
Вы должны увидеть несколько запущенных процессов httpd.
```
root        ... /usr/sbin/httpd -DFOREGROUND
apache      ... /usr/sbin/httpd -DFOREGROUND
...output omitted...
```
Попытайтесь получить доступ к веб-странице.

Теперь попробуйте получить доступ к своей веб-странице с помощью curl. Поскольку вы находитесь на той же машине, вы можете использовать localhost.
```
curl http://localhost/index.html
```
Примечание: В этой конкретной среде вы можете обнаружить, что веб-страница доступна даже с контекстом root_t. Это демонстрирует, что, хотя SELinux и применяется, контекст root_t может иметь более широкие разрешения, чем ожидалось. Однако для соблюдения лучших практик безопасности и правильной настройки SELinux веб-контент по-прежнему должен использовать соответствующий контекст httpd_sys_content_t.
```
This is custom web content.
```
Проверьте текущий контекст SELinux пользовательского каталога.

Используйте команду ls -Z, чтобы просмотреть контекст SELinux вашего каталога /custom и файла index.html.
```
ls -Zd /custom /custom/index.html
```
Вы заметите, что у них контекст root_t, который не является рекомендуемым контекстом для веб-контента Apache.
```
system_u:object_r:root_t:s0 /custom
system_u:object_r:root_t:s0 /custom/index.html
```
Сравните это с корневым каталогом документов Apache по умолчанию:
```
ls -Zd /var/www/html
```
Вы увидите, что /var/www/html имеет контекст httpd_sys_content_t. Это контекст, который вам нужно применить к вашему пользовательскому каталогу.
```
system_u:object_r:httpd_sys_content_t:s0 /var/www/html
```
Определите постоянное правило контекста файла SELinux для /custom.

Команда semanage fcontext используется для управления правилами сопоставления контекста файлов SELinux. Опция -a добавляет новое правило, -t указывает целевой тип, а регулярное выражение '/custom(/.*)?' соответствует самому каталогу /custom и всем файлам и подкаталогам в нем.
```
sudo semanage fcontext -a -t httpd_sys_content_t '/custom(/.*)?'
```
Эта команда добавляет правило в политику SELinux, но она не сразу изменяет контексты существующих файлов.
Примените новые контексты SELinux к файлам.

Команда restorecon используется для восстановления контекстов SELinux файлов и каталогов до их значений по умолчанию, определенных политикой. Опция -R применяет изменение рекурсивно, а -v обеспечивает подробный вывод.
```
sudo restorecon -Rv /custom
```
Вы должны увидеть вывод, указывающий на то, что контексты /custom и /custom/index.html были переназначены.
```
Relabeled /custom from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
Relabeled /custom/index.html from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
```
Проверьте контексты снова, используя ls -Z.
```
ls -Zd /custom /custom/index.html
```
Теперь они должны иметь контекст httpd_sys_content_t.
```
system_u:object_r:httpd_sys_content_t:s0 /custom
system_u:object_r:httpd_sys_content_t:s0 /custom/index.html
```
Снова получите доступ к веб-странице.

Теперь, когда контексты SELinux верны, попробуйте снова получить доступ к веб-странице с помощью curl.
```
curl http://localhost/index.html
```
Теперь вы должны увидеть содержимое вашего файла index.html.
```
This is custom web content.
```
Наконец, остановите процесс веб-сервера Apache HTTP.
```
sudo pkill httpd
```
Убедитесь, что процессы httpd не запущены.
```
ps aux | grep httpd
```
Вы должны увидеть только сам процесс grep.
```
labex     ... grep httpd
```

Настройка политики SELinux для домашних каталогов пользователей с использованием булевых переменных

На этом шаге вы узнаете, как настроить политику SELinux с помощью булевых переменных, чтобы разрешить Apache обслуживать веб-контент из домашних каталогов пользователей. По умолчанию SELinux запрещает таким службам, как Apache, доступ к файлам в домашних каталогах пользователей по соображениям безопасности. Однако существуют конкретные сценарии, такие как личные веб-страницы, где эта функциональность желательна.

Булевы переменные SELinux — это параметры true/false, которые позволяют администраторам изменять поведение политики SELinux без написания сложных пользовательских политик. Они предоставляют гибкий способ включения или отключения определенных функций безопасности. Например, существует булева переменная, специально предназначенная для разрешения Apache доступа к домашним каталогам пользователей.

Включите функцию каталога пользователя Apache.

У Apache есть модуль под названием mod_userdir, который позволяет пользователям публиковать веб-контент из каталога public_html в своем домашнем каталоге (например, ~/public_html). Эта функция обычно настраивается в /etc/httpd/conf.d/userdir.conf. По умолчанию эта функция часто отключена.

Откройте файл конфигурации с помощью nano.
```
sudo nano /etc/httpd/conf.d/userdir.conf
```
Внутри редактора вы найдете строки, связанные с UserDir. Вам нужно закомментировать строку, которая отключает UserDir, и раскомментировать строку, которая включает ее для public_html.

Измените:
```
UserDir disabled
#UserDir public_html
```
На:
```
#UserDir disabled
UserDir public_html
```
Сохраните и выйдите из файла (Ctrl+X, Y, Enter).
Создайте каталог public_html и файл index.html в своем домашнем каталоге.

Вы создадите каталог public_html и файл index.html внутри него. Здесь будет находиться ваш личный веб-контент.
```
mkdir ~/public_html
echo 'This is labex user content.' > ~/public_html/index.html
```
Проверьте содержимое файла index.html.
```
cat ~/public_html/index.html
```
```
This is labex user content.
```
Информационно: Когда вы создали каталог ~/public_html, он был автоматически настроен с контекстами user_home_t и ~/ (ваш домашний каталог) с контекстами home_dir_t SELinux. Процесс веб-сервера Apache (httpd_t) не может читать файлы с меткой user_home_t или home_dir_t по умолчанию из-за политики SELinux.
Запустите веб-службу Apache.

Запустите службу httpd. Помните, что systemctl недоступен в этой среде контейнера, поэтому вы запустите httpd напрямую.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
Вы можете увидеть предупреждающее сообщение о полном доменном имени сервера, которое можно спокойно игнорировать в этой лабораторной среде.

Убедитесь, что Apache работает.
```
ps aux | grep httpd
```
```
root        ... /usr/sbin/httpd -DFOREGROUND
apache      ... /usr/sbin/httpd -DFOREGROUND
...output omitted...
```
Попытайтесь получить доступ к веб-странице пользователя и наблюдайте отказ SELinux.

Теперь попробуйте получить доступ к своей личной веб-странице с помощью curl. URL-адрес для пользовательских каталогов обычно имеет формат http://localhost/~username/.
```
curl http://localhost/~labex/index.html
```
Вы, вероятно, получите ошибку "Forbidden" (Запрещено), указывающую на то, что Apache по-прежнему не может получить доступ к контенту из-за SELinux.
```
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /~labex/index.html
on this server.<br />
</p>
</body></html>
```
Проверьте булевы переменные SELinux, связанные с домашними каталогами для httpd.

Команда getsebool позволяет просмотреть текущее состояние булевых переменных SELinux. Вы можете отфильтровать вывод с помощью grep, чтобы найти булевы переменные, связанные с httpd и домашними каталогами.
```
sudo getsebool -a | grep httpd | grep home
```
Вы должны увидеть httpd_enable_homedirs --> off, что указывает на то, что эта булева переменная в настоящее время отключена.
```
httpd_enable_homedirs --> off
```
Включите булеву переменную httpd_enable_homedirs постоянно.

Команда setsebool используется для изменения состояния булевых переменных SELinux. Опция -P делает изменение постоянным после перезагрузок.
```
sudo setsebool -P httpd_enable_homedirs on
```
Убедитесь, что булева переменная теперь включена (on).
```
sudo getsebool -a | grep httpd | grep home
```
```
httpd_enable_homedirs --> on
```
Установите правильные разрешения на файлы для домашнего каталога.

Даже если булева переменная SELinux включена, Apache нужны правильные разрешения файловой системы для доступа к вашему домашнему каталогу и каталогу public_html. По умолчанию домашние каталоги пользователей недоступны для пользователя Apache.
```
chmod 711 ~
chmod 755 ~/public_html
chmod 644 ~/public_html/index.html
```
Снова получите доступ к веб-странице.

Теперь, когда булева переменная httpd_enable_homedirs включена и разрешения на файлы установлены правильно, попробуйте снова получить доступ к своей личной веб-странице с помощью curl.
```
curl http://localhost/~labex/index.html
```
Теперь вы должны увидеть содержимое вашего файла index.html.
```
This is labex user content.
```
Устранение неполадок: Если вы все еще сталкиваетесь с проблемами доступа даже после включения булевой переменной и установки разрешений на файлы, это демонстрирует многослойный характер безопасности Linux. В некоторых средах дополнительные факторы, такие как:
- Директивы конфигурации Apache в /etc/httpd/conf.d/userdir.conf
- Контексты файлов SELinux в структуре домашнего каталога
- Дополнительные модули Apache или параметры безопасности
возможно, потребуется решить. Ключевым моментом обучения является понимание того, как булевы переменные SELinux работают в сочетании с традиционными разрешениями на файлы и конфигурациями, зависящими от приложений.
Остановите процесс веб-сервера Apache HTTP.

Наконец, остановите процесс веб-сервера Apache HTTP.
```
sudo pkill httpd
```
Убедитесь, что процессы httpd не запущены.
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

Устранение неполадок с отказами SELinux для веб-сервера Apache

На этом шаге вы узнаете, как идентифицировать и устранять неполадки с отказами безопасности SELinux, уделяя особое внимание проблемам, которые могут помешать правильной работе веб-сервера Apache. Когда SELinux блокирует операцию, он регистрирует сообщение об отказе "Access Vector Cache" (AVC). Эти сообщения имеют решающее значение для понимания того, почему операция завершилась неудачей, и как ее решить.

Вы будете использовать такие инструменты, как auditd (демон системы аудита Linux) и sealert, для анализа этих сообщений об отказе. auditd собирает системные вызовы и события, включая отказы SELinux, и сохраняет их в /var/log/audit/audit.log. Инструмент sealert, входящий в пакет setroubleshoot-server, может анализировать эти журналы и предоставлять понятные для человека объяснения и предлагаемые решения для отказов SELinux.

Сначала вам нужно убедиться, что auditd и setroubleshoot-server установлены.

Установите auditd и setroubleshoot-server.
```
sudo dnf install -y audit setroubleshoot-server
```
Вы должны увидеть вывод, указывающий на успешную установку этих пакетов.
Запустите веб-сервер Apache и создайте проблемный файл.

Чтобы смоделировать отказ SELinux, вы создадите файл с неверным контекстом SELinux и попытаетесь обслужить его с помощью Apache.

Сначала убедитесь, что Apache работает.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
Теперь создайте новый каталог и файл index.html в нем. На этот раз вы намеренно установите неверный контекст SELinux для этого файла, чтобы вызвать отказ.
```
sudo mkdir /testweb
echo 'This is a test page.' | sudo tee /testweb/index.html
```
По умолчанию /testweb/index.html, вероятно, будет иметь контекст root_t. Давайте подтвердим.
```
ls -Z /testweb/index.html
```
```
system_u:object_r:root_t:s0 /testweb/index.html
```
Теперь давайте настроим Apache для обслуживания из /testweb. Откройте /etc/httpd/conf/httpd.conf.
```
sudo nano /etc/httpd/conf/httpd.conf
```
Измените DocumentRoot и директиву <Directory> на /testweb.
```
DocumentRoot "/testweb"

<Directory "/testweb">
    AllowOverride None
    Require all granted
</Directory>
```
Сохраните и выйдите (Ctrl+X, Y, Enter).

Перезапустите Apache, чтобы применить изменения конфигурации. Поскольку вы находитесь в контейнере, вам нужно убить старый процесс и запустить новый.
```
sudo pkill httpd
sudo /usr/sbin/httpd -DFOREGROUND &
```
Попытайтесь получить доступ к веб-странице.

Попробуйте получить доступ к веб-странице с помощью curl.
```
curl http://localhost/index.html
```
Важное примечание: В этой среде вы можете обнаружить, что веб-страница доступна даже с контекстом root_t, аналогично тому, что мы наблюдали на шаге 2. Это демонстрирует, что, хотя SELinux и применяется, контекст root_t имеет более широкие разрешения, чем более ограничительные контексты.
```
This is a test page.
```
Однако для целей изучения методов устранения неполадок SELinux мы продолжим, как если бы был отказ. В более ограничительных средах SELinux или с другими конфигурациями политик доступ к файлам с неподходящими контекстами действительно приведет к генерации отказов.
Узнайте об исследовании отказов SELinux с помощью ausearch.

Команда ausearch используется для запроса журналов аудита. Вы можете выполнить поиск отказов AVC SELinux (-m AVC), произошедших сегодня (-ts today).
```
sudo ausearch -m AVC -ts today
```
Примечание: Поскольку веб-страница была доступна в нашей среде, вы можете не увидеть каких-либо недавних отказов AVC, связанных с этим конкретным тестом. Однако эта команда обычно выводит подробные записи журнала аудита, если были отказы. В типичном сценарии отказа вы будете искать записи, связанные с httpd и /testweb/index.html.

Типичная запись об отказе AVC будет выглядеть следующим образом:
```
----
time->...
type=AVC msg=audit(...): avc:  denied  { getattr } for  pid=... comm="httpd" path="/testweb/index.html" dev="overlay" ino=... scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0
...output omitted...
```
Ключевыми частями в отказе AVC будут:
- denied { getattr }: Операция, в которой было отказано (получение атрибутов файла).
- comm="httpd": Процесс, которому было отказано (веб-сервер Apache HTTP).
- path="/testweb/index.html": Файл, к которому был осуществлен доступ.
- scontext=system_u:system_r:httpd_t:s0: Контекст SELinux источника (Apache).
- tcontext=system_u:object_r:root_t:s0: Контекст SELinux цели (ваш файл index.html).
- tclass=file: Тип цели (файл).
Этот вывод четко показывает, что httpd_t (Apache) было отказано в доступе getattr к файлу с контекстом default_t.
Узнайте об использовании sealert для анализа SELinux.

sealert может анализировать журналы аудита и предоставлять более удобную для пользователя информацию. Вы можете либо запустить sealert -a, чтобы проанализировать все недавние отказы, либо использовать sealert -l <UUID>, если у вас есть конкретный UUID из сообщения setroubleshoot в /var/log/messages.
```
sudo sealert -a /var/log/audit/audit.log
```
Примечание: Поскольку мы не сталкивались с фактическими отказами в этой среде, запуск sealert может не показать результаты, связанные с нашим примером /testweb. Однако в сценарии, когда происходят отказы SELinux, sealert будет анализировать журнал аудита и представлять сводку.

Типичный вывод sealert для проблемы с контекстом httpd будет выглядеть следующим образом:
```
SELinux is preventing /usr/sbin/httpd from getattr access on the file /testweb/index.html.

***** Plugin catchall_labels (83.8 confidence) suggests *******************
If you want to allow httpd to have getattr access on the index.html file
Then you need to change the label on /testweb/index.html
Do ## semanage fcontext -a -t FILE_TYPE '/testweb/index.html'
where FILE_TYPE is one of the following:
httpd_sys_content_t, httpd_sys_script_exec_t, httpd_unconfined_script_exec_t, ...

***** Plugin httpd_can_network_connect (93.8 confidence) suggests *********
If you want to allow httpd to connect to the network (for example, to a database)
Then you must set the httpd_can_network_connect boolean to on.
Do ## setsebool -P httpd_can_network_connect on
...output omitted...
```
Вывод sealert был бы очень полезен в реальных сценариях отказа. Он бы четко указывал на проблему и предлагал решения, такие как изменение метки с помощью semanage fcontext -a -t FILE_TYPE '/testweb/index.html' и перечисление httpd_sys_content_t в качестве подходящего FILE_TYPE.

Наконец, остановите процесс веб-сервера Apache HTTP.
```
sudo pkill httpd
```
Убедитесь, что процессы httpd не запущены.
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

Решение проблем SELinux для пользовательского веб-контента

На этом заключительном шаге вы примените знания, полученные в предыдущем упражнении по устранению неполадок, чтобы решить проблему с отказом SELinux, которая не позволяла Apache обслуживать контент из каталога /testweb. Вы будете использовать semanage fcontext для определения правильного контекста SELinux для вашего пользовательского веб-контента и restorecon для его применения.

Этот процесс закрепляет понимание того, как работают контексты SELinux и как правильно их настраивать для таких служб, как Apache.

Убедитесь, что Apache работает и конфигурация настроена.

Сначала убедитесь, что Apache настроен для обслуживания из /testweb и работает. Если вы остановили Apache на предыдущем шаге, запустите его снова.
```
sudo /usr/sbin/httpd -DFOREGROUND &
```
Убедитесь, что DocumentRoot в /etc/httpd/conf/httpd.conf установлен в /testweb. Если нет, измените его, как это было сделано на предыдущем шаге.
```
grep "DocumentRoot" /etc/httpd/conf/httpd.conf
```
```
DocumentRoot "/testweb"
```
Кроме того, убедитесь, что /testweb/index.html существует и имеет контекст root_t.
```
ls -Z /testweb/index.html
```
```
system_u:object_r:root_t:s0 /testweb/index.html
```
Получите доступ к веб-странице, чтобы подтвердить текущее поведение.

Давайте убедимся, что веб-страница в настоящее время доступна с контекстом root_t.
```
curl http://localhost/index.html
```
Как мы видели ранее, страница доступна даже с контекстом root_t.
```
This is a test page.
```
Хотя это работает, мы продолжим демонстрировать правильную конфигурацию SELinux для веб-контента.
Определите правильный контекст файла SELinux для /testweb.

Правильный контекст SELinux для веб-контента, обслуживаемого Apache, — httpd_sys_content_t. Вам нужно добавить постоянное правило, используя semanage fcontext.
```
sudo semanage fcontext -a -t httpd_sys_content_t '/testweb(/.*)?'
```
Эта команда сообщает SELinux, что все файлы или каталоги в /testweb (включая сам /testweb) должны быть помечены как httpd_sys_content_t.
Примените новые контексты SELinux к файлам.

После определения правила необходимо применить его к существующим файлам с помощью restorecon.
```
sudo restorecon -Rv /testweb
```
Вы должны увидеть вывод, указывающий на то, что контексты были переназначены.
```
Relabeled /testweb from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
Relabeled /testweb/index.html from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
```
Снова проверьте контексты с помощью ls -Z.
```
ls -Z /testweb/index.html
```
```
system_u:object_r:httpd_sys_content_t:s0 /testweb/index.html
```
Снова получите доступ к веб-странице, чтобы подтвердить правильную конфигурацию.

Теперь, когда контексты SELinux правильно применены в соответствии с лучшими практиками, попробуйте еще раз получить доступ к веб-странице с помощью curl.
```
curl http://localhost/index.html
```
Контент по-прежнему должен быть доступен, и теперь он правильно настроен с рекомендуемым контекстом SELinux.
```
This is a test page.
```
Это демонстрирует, что, хотя контекст root_t может работать в этой среде, использование правильного контекста httpd_sys_content_t соответствует лучшим практикам SELinux и обеспечивает совместимость в различных конфигурациях безопасности.

Наконец, остановите процесс веб-сервера Apache HTTP.
```
sudo pkill httpd
```
Убедитесь, что процессы httpd не запущены.
```
ps aux | grep httpd
```
```
labex     ... grep httpd
```

Резюме

В этой лабораторной работе вы научились управлять безопасностью SELinux в RHEL. Вы начали с понимания и практики изменения режимов принудительного применения SELinux, как временно с помощью setenforce, так и постоянно путем изменения /etc/selinux/config. Это включало в себя проверку текущего режима с помощью getenforce и понимание последствий режимов Enforcing (Принудительный), Permissive (Разрешающий) и Disabled (Отключен).

Кроме того, вы получили практический опыт настройки Apache с пользовательскими контекстами файлов SELinux, используя semanage fcontext и restorecon, чтобы обеспечить правильную работу веб-сервера. Вы также научились настраивать политику SELinux для домашних каталогов пользователей, включив определенные булевы значения SELinux с помощью setsebool. Наконец, в лабораторной работе были рассмотрены основные методы устранения неполадок для отказов SELinux, в частности, для веб-сервера Apache, путем анализа журналов аудита с помощью ausearch и audit2allow для выявления и решения проблем доступа к пользовательскому веб-контенту.

Управление безопасностью SELinux в RHEL