Установка пользовательской политики SELinux для сервиса systemd

В AlmaLinux9 у меня есть небольшой сервис systemd ExectStart, который запускает процесс Java (Java Temurin 21). У меня возникают ошибки SELinux из-за того, что у сервиса нет разрешения execmem (уже проверил журналы AVC).

Инструмент audit2allow рекомендует предоставить домену unit_t разрешения execmem, это рекомендованная политика для установки:

module my-java 1.0;

require {
        type init_t;
        class process execmem;
}

#============= init_t ==============
allow init_t self:process execmem;

Я не хочу давать каждому процессу init_t привилегии execmem, так как я могу определить собственную политику SELinux / переход политики, который будет применяться только к этому конкретному сервису?

Кроме того, исполняемый файл java работает нормально, если я запускаю его напрямую, это связанные домены SELinux.

system_u:object_r:lib_t:s0 /usr/lib/jvm/temurin-21-jre/bin/java

Из вашего вопроса я делаю следующие предположения:

• Ваш сервис работает как init_t
• Файл юнита вашего сервиса имеет ExecStart=/usr/lib/jvm/temurin-21-jre/bin/java -jar something.jar
• Тип /usr/lib/jvm/temurin-21-jre/bin/java – это lib_t.

В таком случае первое, что нужно исправить, это убедиться, что ваш сервис не работает как init_t. init_t должен использоваться только системой инициализации. Отдельные сервисы должны использовать типы, созданные специально для них (например, веб-сервера должны работать как httpd_t). Существует тип для пользовательских сервисов, называемый unconfined_service_t, и, как следует из названия, он не подвержен строгому ограничению.

Итак, почему ваш сервис работает как init_t? Это происходит потому, что исполняемый файл помечен как lib_t, и нет правила перехода типа, которое вызывает автоматический переход от init_t к чему-то еще, когда исполняемый файл с меткой lib_t выполняется:

# sesearch -T -s init_t -c process -t lib_t | wc -l
0

Давайте поищем правила переходов, которые позволят init_t перейти к unconfined_service_t:

$ sudo sesearch -T -s init_t -c process -D unconfined_service_t
type_transition init_t bin_t:process unconfined_service_t;
type_transition init_t usr_t:process unconfined_service_t;

Следовательно, если ваш исполняемый файл помечен как bin_t или usr_t, то ваш сервис будет запускаться как unconfined_service_t. Это логично, так как эти типы используются для файлов в /usr/bin и /usr/libexec и так далее. Поэтому следующая задача – убедиться, что исполняемый файл помечен одним из этих типов.

Здесь вступает в силу одно из самых важных руководств по управлению системой SELinux. Резюме: не помещайте вещи в странные места.

Например, httpd_t разрешено читать файлы с меткой httpd_sys_content_t, и для этого по умолчанию настроена метка файловой системы, так что эта метка применяется к файлам в /var/www. Следовательно, это плохая идея помещать файлы, предназначенные для обслуживания веб-сервером, за пределами этой директории. Это не говорит о том, что вы не можете так делать; только о том, что если вы настаиваете на этом, то вы создали дополнительную работу для себя, чтобы убедиться, что файлы получают правильные метки.

То же самое касается вашей JVM. Она находится в нетрадиционном расположении, и поэтому метки файловой системы по умолчанию для ее исполняемых файлов – lib_t (ошибка), вместо bin_t (правильно). Чтобы продемонстрировать это, сравните результаты следующих двух команд, которые проверяют заданные пути для определения их меток файлов по умолчанию. Первый путь поставляется с java-21-openjdk-headless, второй – из вашей JVM:

$ matchpathcon /usr/lib/jvm/java-21-openjdk-21.0.5.0.11-1.fc41.x86_64/bin/java
/usr/lib/jvm/java-21-openjdk-21.0.5.0.11-1.fc41.x86_64/bin/java system_u:object_r:bin_t:s0

$ matchpathcon /usr/lib/jvm/temurin-21-jre/bin/java
/usr/lib/jvm/temurin-21-jre/bin/java    system_u:object_r:lib_t:s0

Итак, если ваша JVM находится в неправильном месте, куда нам нужно ее переместить? Мы можем выяснить это, изучив список путей и их меток файлов по умолчанию:

$ sudo semanage fcontext -l | grep /usr/lib/jvm | grep bin_t
/usr/lib/jvm/java(.*/)bin(/.*)                     all files          system_u:object_r:bin_t:s0 

Таким образом, если вы согласны с перемещением вашей JVM, все, что вам нужно сделать, это поместить ее в папку, которая соответствует этому регулярному выражению, выполнить restorecon -rv на /usr/lib/jvm (что сбрасывает метки файлов на диске, чтобы они соответствовали их значениям по умолчанию) и перезапустить ваш сервис, и он теперь должен правильно перейти к unconfined_service_t. Мы можем протестировать подходящий путь файла с помощью matchpathcon:

$ matchpathcon /usr/lib/jvm/java-temurin-21-jre/bin/java
/usr/lib/jvm/java-temurin-21-jre/bin/java   system_u:object_r:bin_t:s0

Если вы не можете переместить JVM, то вы можете настроить метку файловой системы по умолчанию для исполняемых файлов в их существующем пути с помощью команды вроде semanage fcontext --add -t bin_t /usr/lib/jvm/temurin-\d+-jre/bin(/.*), за которой следует restorecon и перезапуск вашего сервиса, как описано выше.

Теперь, когда ваш сервис запускается с правильной меткой (unconfined_service_t), давайте проверим, разрешено ли ему разрешение execmem:

# sesearch -A -s unconfined_service_t -c process -p execmem
allow unconfined_service_t unconfined_service_t:process execmem; [ deny_execmem ]:False

Похоже, что это будет разрешено, само при условии, что булевый флаг deny_execmem не установлен. Этот булевый флаг описан в мануале unconfined_service_selinux(8):

Если вы хотите запретить приложениям доменов пользователя отображать область памяти как исполняемую и записываемую, это опасно, и исполняемый файл должен быть сообщен в bugzilla, вам нужно включить булевый флаг deny_execmem. Отключен по умолчанию.

setsebool -P deny_execmem 1

Вы можете проверить, включён ли он в вашей системе с помощью getsebool deny_ptrace; пока он выключен, SELinux не будет препятствовать вашему сервису, работающему как unconfined_service_t, отображать свои страницы как записываемые и исполняемые.

(Меня на самом деле удивляет, что это не отключено по умолчанию в 2024 году…)