У меня есть система CentOS 7, в которой я использую postfix в качестве MTA. Некоторые пользователи используют procmail через .forward
свои домашние каталоги:
# cat .forward
"|exec /usr/bin/procmail -f- || exit 75"
В этом случае мне сложно понять, почему SELinux не позволяет procmail выполнить dspam из .procmailrc
:
:0fw: dspam.lock
| /usr/bin/dspam --client --stdout --deliver=spam,innocent
В журнале procmail я получаю:
procmail: Locking "dspam.lock"
procmail: Executing "/usr/bin/dspam,--client,--stdout,--deliver=spam,innocent"
/bin/sh: /usr/bin/dspam: Permission denied
procmail: Program failure (126) of "/usr/bin/dspam"
procmail: Rescue of unfiltered data succeeded
procmail: Unlocking "dspam.lock"
Однако если я устанавливаю SELinux в разрешающий режим, то все работает нормально.
Проблема в том, что он не регистрирует никаких сообщений AVC о том, что отклоняется. Когда я впервые настраивал все это, я нашел некоторые пробелы через audit2why
и ausearch
и исправил их. Теперь я ничего не получаю, хотя это явно SELinux мешает ему работать.
Редактировать: Вот двоичный файл dspam:
# ls -lZ /usr/bin/dspam
-r-x--s--x. dspam mail system_u:object_r:dspam_exec_t:s0 /usr/bin/dspam
решение1
У меня очень похожая проблема. В моем случае selinux тихонько мешает выполнению кода в моей папке .procmailbin (я уже установил контекст по умолчанию для .procmailbin на procmail_exec_t).
Я пока не решил проблему, но считаю, что путь к ответу — указать selinux сообщатьвсеотрицания, которые он делаетнетделать по умолчанию.
Чтобы включить полную отчетность обо всех отказах, используйте следующее:
semodule --disable_dontaudit --build
Просмотрите файл Audit.log и используйте sealert по мере необходимости, чтобы определить, что происходит.
Затем, чтобы вернуть все в нормальное состояние, используйте:
semodule --build
Удачи! В моем случае я нахожусь в точке, когда sealert показывает мне эту информацию, которая раньше не появлялась:
SELinux is preventing sh from search access on the directory /home/chris/.procmailbin.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that sh should be allowed search access on the .procmailbin directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sh' --raw | audit2allow -M my-sh
# semodule -X 300 -i my-sh.pp
... но мне все еще нужно проверить, является ли это реальной проблемой и каково наилучшее решение.
Обновление: Оказывается, это решило мою проблему.
Вот содержимое созданного мной пользовательского модуля:
# more procmailbin-sh-search.te
module my-sh 1.0;
require {
type dmesg_t;
type procmail_t;
type procmail_exec_t;
type abrt_t;
class dir search;
class process noatsecure;
}
#============= abrt_t ==============
allow abrt_t dmesg_t:process noatsecure;
#============= procmail_t ==============
allow procmail_t procmail_exec_t:dir search;
Мне кажется, это должно быть поведением по умолчанию, так что, думаю, попробую выяснить, кому сообщить об этой «ошибке».
решение2
Итак, посмотрев на ответ Криса Беннета, я использовал его semodule --disable_dontaudit
и смог понять, что мне нужно. Вот что у меня получилось, чтобы заставить postfix+procmail+dspam работать:
require {
type dspam_rw_content_t;
type dspam_t;
type dspam_exec_t;
type procmail_t;
class dir { open read write getattr add_name search };
class file { append getattr lock open read write setgid };
class unix_stream_socket connectto;
}
#============= dspam_t ==============
allow dspam_t dspam_rw_content_t:dir { open read write getattr add_name search };
allow dspam_t dspam_rw_content_t:file { append getattr lock open write };
#============= procmail_t ==============
allow procmail_t dspam_exec_t:file { open read setgid };
allow procmail_t dspam_t:unix_stream_socket connectto;