SELinux и Dovecot - не работает

Postfix, Dovecot и LDAP входят в стандартную поставку centos6. Это значит, что selinux для всех троих уже должен быть настроен правильно и работать «из коробки». Возможно, с некоторой модификацией selinux boolean.

grep rsync /var/log/audit/audit.log | audit2allow -M mypol

2. модуль, созданный audit2allow, очень часто требует напильника. Видимо, для упрощения он разрешает больше, чем требуется.

sealert -a /var/log/audit/audit.log

а если так:

tail -f /var/log/audit/audit.log | grep 'avc'

grep rsync /var/log/audit/audit.log | audit2allow -M mypol

Это просто пример.

 $ sealert -a /var/log/audit/audit.log                                                                                                                
100% donefound 0 alerts in /var/log/audit/audit.log

cat /var/log/audit/audit.log | grep 'avc'

Выдает пустой вывод.

Вроде как SELinux ничего не блокирует. Однако Dovecot не работает.

У меня ощущение, что с включенным SELinux появляются непонятки с владельцем сокета auth-userdb, но как проверить не знаю - опыта работы с SELinux маловато.

Postfix, Dovecot и LDAP входят в стандартную поставку centos6. Это значит, что selinux для всех троих уже должен быть настроен правильно и работать «из коробки».

Возможно это для каждого из них поотдельности правильно, но в связке есть проблемы.

Спасибо за желание помочь - тема не самая распространенная, каждый знающий человек почти на вес золота :)

появляются непонятки с владельцем сокета

selinux не имеет отношения к правам/владельцам. Он как бы отдельно.

Я бы делал так:

1. Вытер модуль, сделанный audit2allow, чтобы привести всё в первоначальное состояние.

2. Собрал статистику блокировок доступа через `cat /var/log/audit/audit.log | grep 'avc'`.

3. Чинил каждый отлуп отдельно через исправление контекстов файлов/сокетов или selinux booleans. Может понадобится и модуль, если всё совсем плохо.

Возможно это для каждого из них поотдельности правильно, но в связке есть проблемы.

В redhat за этим следят. Вероятно, в centos что-то забыли, или что-то из связки ставилось через `make install` в обход пакетного менеджера?

Собрал статистику блокировок доступа через `cat /var/log/audit/audit.log | grep 'avc'

Чинил каждый отлуп отдельно через исправление контекстов файлов/сокетов или selinux booleans

Именно так и делал, но сообщение

Feb 19 17:49:22 mailserver dovecot: lda: Error: userdb lookup: connect(/var/run/dovecot//auth-userdb) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /var/run/dovecot//auth-userdb, euid is not dir owner)

что-то из связки ставилось через `make install` в обход пакетного менеджера

Вроде все из пакетов ставилось, но ставилось при выключенном SELinux

Вроде все из пакетов ставилось, но ставилось при выключенном SELinux

Это не имеет значения в том случае, если selinux был в permissive режиме. Если же был он был 'disabled', необходимо сделать полное восстановление контекстов файлов системы. Кстати, в разрешающем режиме ошибки должны появляться в audit.log точно так же, как и при нормальном режиме, но блокировок не происходит. Этот режим отладки именно то, что нужно для тестирования.

# getenforce
Enforcing //нормальный режим работы
# setenforce 0
# getenforce
Permissive //режим отладки

Почта продолжит ходить как при отключенном selinux, но можно наблюдать за ошибками доступа и пытаться что-то исправлять, следя за результатами в audit.log. Без отрыва сервера от производства.

Вот тут похожая проблема: http://bugs.centos.org/view.php?id=5831 Решилась выставлением правильных контекстов, а сообщение об ошибке от dovecot содержит всё ту же ругань на владельца.

Все именно так и было: востановление контекстов, Permissive режим, наблюдение и исправление ошибок. Но засада в том что ошибка доступа не появляется пока не переводишь SELinux в боевой режим, да и в этом случае она появляется только в /var/log/maillog

Вот тут похожая проблема: http://bugs.centos.org/view.php?id=5831 Решилась выставлением правильных контекстов, а сообщение об ошибке от dovecot содержит всё ту же ругань на владельца.

Спасибо, завтра на работе попробую. По результату отпишусь обязательно.

Такое бывает. Нужно отключить модуль, порождённый audit2allow и посмотреть на ошибки. Вероятно, проблема их исчезновения в нём.

Спасибо. Завтра на работе поэкспериментирую. По результатам отпишусь.

Вот для сравнения права доступа на auth-userdb на сервере(rhel6):

[root@localhost-1-32 dovecot]# pwd
/var/run/dovecot
[root@localhost-1-32 dovecot]# ll -Z auth-userdb 
srw-------. root root unconfined_u:object_r:dovecot_var_run_t:s0 auth-userdb

Отличия - владелец root. Контекст такой же.

Dovecot запущен с контекстом dovecot_t:

[root@localhost-1-32 dovecot]# ps auxZ | fgrep dovecot
unconfined_u:system_r:dovecot_t:s0 root  24552  0.0  0.0  19252   860 ?        Ss   14:51   0:00 /usr/sbin/dovecot
unconfined_u:system_r:dovecot_t:s0 dovecot 24554 0.0  0.0 12972  1032 ?        S    14:51   0:00 dovecot/anvil
unconfined_u:system_r:dovecot_t:s0 root  24555  0.0  0.0  13100  1144 ?        S    14:51   0:00 dovecot/log
unconfined_u:system_r:dovecot_t:s0 root  24557  0.0  0.0  15076  3176 ?        S    14:51   0:00 dovecot/config

Доступ на этот fifo тоже есть (write):

[root@localhost-1-32 dovecot]# sesearch --allow -s dovecot_t -c fifo_file
...
   allow dovecot_t dovecot_var_run_t : fifo_file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
...

Решил сделать так: установил с нуля CentOS. С включенным SELinux настроил Postfix+Dovecot+LDAP. В процессе настройки поправил только контекст к папке хранения почты виртуальных пользователей - больше ни на что SELinux не ругался. И опять тоже самое:

Feb 21 23:51:46 localhost dovecot: lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +r perm: /var/run/dovecot/auth-userdb, euid is not dir owner)
Feb 21 23:51:46 localhost dovecot: lda: Fatal: Internal error occurred. Refer to server log for more information.

Бред какой-то!

Вот ещё похожая и достаточно свежая проблема: http://www.dovecot.org/list/dovecot/2013-January/070525.html

Есть! Заработало!

Пока правда без Amavis-а, spamassassina, sieve ... Но заработало. Теперь прикручу всю эту обвязку и распишу что делал - может кому пригодится.

fjoe огромное спасибо за помощь.

В общем как и обещал - отчитываюсь.

Проблема была, как выяснилось, не в Dovecote, а в Postfix-е. А точнее в строке

master.cf
dovecot    unix    -    n    n    -    -    pipe
  flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver -f ${sender} -d ${recipient} # Так работает
#  flags=DRhu user=vmail:vmail argv=/usr/bin/spamc -u vmail -e /usr/libexec/dovecot/deliver -f ${sender} -d ${recipient} - Так выдает ошибку

Почему так - пока не разобрался. Подозреваю, что дело в междоменных переходах, но решения пока не придумал, да и не уверен что буду придумывать.

Еще раз огромное спасибо fjoe.

Спасибо