Как создать исключение SELinux для отдельных файлов

Вопрос или проблема

Я использую инструмент мониторинга, и на одной из моих систем, которая проверяется удаленно, вызывается скрипт, который, в свою очередь, запускает systemctl, чтобы проверить статус службы. Это не работало, пока я не перевел SELinux в режим разрешений. Однако я не смогу оставить эту систему в режиме разрешений. Мне нужно использовать semanage для исключения и вернуть систему в принудительный режим. Я использовал semanage ранее для процесса, но никогда для файла. Я просмотрел мануал и искал в Google, но не могу разобраться с точной командой, которую мне нужно использовать. Итак, скажем, мне нужно разрешить скрипт с именем “run_this_script” в папке /usr/lib64/application/plugin, какая команда мне нужна с semanage?

ИЗМЕНИТЬ – просто чтобы дать больше контекста относительно того, что я видел в журналах аудита, вот фрагмент.

type=AVC msg=audit(1446051455.169:3313): avc:  denied  { execute }   for  pid=15388 comm="check_init_serv" name="systemctl" dev="dm-1"  ino=2101040 scontext=system_u:system_r:nrpe_t:s0  tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1446051455.169:3313): arch=c000003e  syscall=59 success=no exit=-13 a0=2098450 a1=209ba50 a2=209c680    a3=7fff573ff5b0 items=0 ppid=15386 pid=15388 auid=4294967295 uid=997    gid=995 euid=997 suid=997 fsuid=997 egid=995 sgid=995 fsgid=995 tty=   (none) ses=4294967295 comm="check_init_serv" exe="/usr/bin/bash"   subj=system_u:system_r:nrpe_t:s0 key=(null)

type=AVC msg=audit(1446051455.169:3314): avc:  denied  { getattr }   for  pid=15388 comm="check_init_serv" path="/usr/bin/systemctl"   dev="dm-1" ino=2101040 scontext=system_u:system_r:nrpe_t:s0    tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1446051455.169:3314): arch=c000003e     syscall=4 success=no exit=-13 a0=2098450 a1=7fff573ff780     a2=7fff573ff780 a3=7fff573ff5b0 items=0 ppid=15386 pid=15388     auid=4294967295 uid=997 gid=995 euid=997 suid=997 fsuid=997 egid=995     sgid=995 fsgid=995 tty=(none) ses=4294967295 comm="check_init_serv"     exe="/usr/bin/bash" subj=system_u:system_r:nrpe_t:s0 key=(null)

type=AVC msg=audit(1446051455.169:3315): avc:  denied  { getattr }     for  pid=15388 comm="check_init_serv" path="/usr/bin/systemctl"    dev="dm-1" ino=2101040 scontext=system_u:system_r:nrpe_t:s0     tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1446051455.169:3315): arch=c000003e   syscall=4 success=no exit=-13 a0=2098450 a1=7fff573ff760   a2=7fff573ff760 a3=7fff573ff5b0 items=0 ppid=15386 pid=15388   auid=4294967295 uid=997 gid=995 euid=997 suid=997 fsuid=997 egid=995   sgid=995 fsgid=995 tty=(none) ses=4294967295 comm="check_init_serv"   exe="/usr/bin/bash" subj=system_u:system_r:nrpe_t:s0 key=(null)

type=AVC msg=audit(1446053257.457:3401): avc:  denied  { read } for     pid=15647 comm="systemctl" name="journal" dev="tmpfs" ino=11584    scontext=system_u:system_r:nrpe_t:s0   tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=dir

Не тестировал, но..

найдите нужное имя с помощью audit2allow -a, а затем выполните

  • Активируйте пакет политик: semodule -i <module_name>.pp
  • проверьте, загружен ли модуль: semanage module -l | grep <module_name>
  • затем вернитесь к принудительному режиму: setenforce 1

Я вижу, что вы используете NRPE, удаленный исполнитель плагинов Nagios. Правильный способ сделать это – вызвать NRPE через sudo и сказать SELinux, что NRPE разрешено вызывать sudo.

Убедитесь, что вы разрешили пользователя nrpe в конфигурации sudo, например, сделав:

» cat /etc/sudoers.d/nrpe
Defaults:nrpe !requiretty
nrpe ALL = (root) NOPASSWD: /sbin/service <whatever> status

Определите проверку, замените my_service фактическим именем службы:

» cat /etc/nrpe.d/nrpe_custom_checks.cfg
command[check_my_service]=/usr/lib64/nagios/plugins/check_service_status_sudo my_service

Это будет ваш скрипт проверки:

0» cat /usr/lib64/nagios/plugins/check_service_status_sudo
#!/usr/bin/env bash

# Не используйте -e, так как мы ожидаем, что команды могут завершиться неудачей
set -uo pipefail

OK=0
WARN=1
CRIT=2
UNKNOWN=3
STATE=${UNKNOWN}
MSG=""

if [[ $# -ne 1 ]]; then
    echo "UNKNOWN - $0 требует один аргумент. Прерывание."
    exit ${UNKNOWN}
fi

SERVICENAME="$1"

OUTPUT=$(/usr/bin/sudo /sbin/service ${SERVICENAME} status 2>&1)
ES=$?

if [[ $ES -eq 0 ]]; then
    STATE=${OK}
    MSG="OK"
elif [[ $ES -eq 1 ]]; then
    # либо не запущен, либо нераспознанная служба
    if echo "${OUTPUT}" | grep -q "unrecognized service"; then
        STATE=${WARN}
        MSG="WARNING"
    else
        STATE=${CRIT}
        MSG="CRITICAL"
    fi
fi

echo "${MSG} - ${OUTPUT}";
exit ${STATE}

Вам возможно нужно настроить этот логический параметр SELinux для вашего случая:

» setsebool -P nagios_run_sudo on

Ответ или решение

Создание исключения SELinux для отдельных файлов: Подробное руководство

Ваша ситуация с SELinux и инструментом мониторинга, который вызывает скрипт для проверки статуса службы, требует точной настройки пол políticas SELinux, чтобы обеспечить функциональность без отключения политики безопасности. Процесс создания исключения SELinux для отдельных файлов включает несколько шагов. В этом руководстве мы разберёмся, как это сделать.

Шаг 1: Анализ ошибок в журнале аудита

Первым делом, вам необходимо ознакомиться с аудиторскими записями, которые вы предоставили. Вот основные моменты, на которые стоит обратить внимание:

  • тип доступа: execute, getattr, read
  • scontext (контекст источника): system_u:system_r:nrpe_t:s0
  • tcontext (контекст цели): system_u:object_r:systemd_systemctl_exec_t:s0

Эти коды показывают, что процесс, выполняемый от имени nrpe_t, не имеет разрешения на выполнение и взаимодействие с файлом, который принадлежит категории systemd_systemctl_exec_t.

Шаг 2: Использование audit2allow для создания модуля

Вам следует использовать инструмент audit2allow, чтобы создать модуль, который позволит необходимый доступ. Выполните следующие команды:

# Генерация модуля политики из логов аудита
audit2allow -a -M my_custom_policy

# Установка созданного модуля
semodule -i my_custom_policy.pp

Это создаст и инициализирует новый модуль, который будет включать правило, разрешающее доступ.

Шаг 3: Проверка загруженного модуля

После выполнения установки модуля важно убедиться, что он загружен и активен:

semanage module -l | grep my_custom_policy

Эта команда показывает все загруженные модули и позволяет убедиться в наличии вашего нового модуля.

Шаг 4: Возвращение режима SELinux в состояние "enforcing"

Как только вы создали и протестировали настройки модулей SELinux, вы можете вернуть систему в режим строгого исполнения:

setenforce 1

Этот шаг обеспечивает сохранение безопасности вашей системы.

Шаг 5: Конфигурация sudo для NRPE

Поскольку вы используете NRPE, настоятельно рекомендуется настроить его с использованием sudo, чтобы обойти ограничения. Добавьте в файл конфигурации /etc/sudoers.d/nrpe следующие строки:

Defaults:nrpe !requiretty
nrpe ALL = (root) NOPASSWD: /sbin/service <имя_сервиса> status

Замените <имя_сервиса> на фактическое имя службы, которую вы проверяете.

Шаг 6: Дополнительные настройки

Вы также можете создать специальный скрипт для проверки статуса службы, как показано в вашем запросе. Убедитесь, что он имеет правильные права и контекст SELinux. Запрос может выглядеть следующим образом:

# Содержимое скрипта check_service_status_sudo
#!/usr/bin/env bash

set -uo pipefail

# Проверка наличия аргументов
if [[ $# -ne 1 ]]; then
    echo "UNKNOWN - $0 needs one argument. Aborting."
    exit 3
fi

SERVICENAME="$1"
OUTPUT=$(/usr/bin/sudo /sbin/service ${SERVICENAME} status 2>&1)
ES=$?

# Формирование ответа
# (Добавьте свою бизнес-логку обработки вывода)

Шаг 7: Применение дополнительных SELinux настроек

Если ещё есть ограничения, вы можете активировать boolean для NRPE:

setsebool -P nagios_run_sudo on

Заключение

Следуя данным шагам, вы сможете создать исключение SELinux для отдельных файлов и сохранить режим "enforcing", что обеспечит необходимый баланс между безопасностью и функциональностью вашей системы. Убедитесь, что проводите регулярные проверки журналов аудита для мониторинга дальнейших проблем и настроек безопасности.

Оцените материал
Добавить комментарий

Капча загружается...