LINUX.ORG.RU

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

 ,


0

1

Доброго времени суток всем.

Исходные данные: OS: CentOS 6.3 Установлена связка Postfix+Dovecot+LDAP. Все работает в штатном режиме. SELinux отключен.

Решил всеже использовать SELinux. Естетсвенно поползли проблемы которые решались командами sealert -a /var/log/audit/audit.log; grep rsync /var/log/audit/audit.log | audit2allow -M mypol , изучением файла mypol.te (чего он там предлагает) и созданием новых политик. Вобщем обычная возня. Но наткнулся на проблему:

- sealert -a /var/log/audit/audit.log отвечает 100% donefound 0 alerts in /var/log/audit/audit.log (тобиш все нормально);

- письма отправленные с сервера локальному пользователю не приходят;

- в /var/log/messages ошибок нет;

- в /var/log/maillog идет ошибка:

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)

Feb 19 17:49:22 mailserver dovecot: lda: Fatal: Internal error occurred. Refer to server log for more information.

У /var/run/dovecot//auth-userdb контекст:

srw-------. vmail vmail unconfined_u:object_r:dovecot_var_run_t:s0 auth-userdb

Вроде тоже все правильно. Но не работает!!! Смущает, что сам SELinux ни на что не ругается. Поиск ответа ничего не дал (может не там искал)

Подскажите хоть в какую сторону рыть (отключить SELinux не предлагать)

Зарание спасибо.

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

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

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

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

а если так:

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

fjoe
()
Ответ на: комментарий от fjoe
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 для всех троих уже должен быть настроен правильно и работать «из коробки».

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

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

Medievist
() автор топика
Ответ на: комментарий от Medievist

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

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

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

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

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

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

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

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

fjoe
()
Ответ на: комментарий от fjoe

Собрал статистику блокировок доступа через `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

Medievist
() автор топика
Ответ на: комментарий от Medievist

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

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

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

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

fjoe
()
Ответ на: комментарий от fjoe

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

Medievist
() автор топика
Ответ на: комментарий от fjoe

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

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

Medievist
() автор топика
Ответ на: комментарий от Medievist

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

fjoe
()
Ответ на: комментарий от Medievist

Вот для сравнения права доступа на 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 } ; 
...

fjoe
()
Ответ на: комментарий от fjoe

Решил сделать так: установил с нуля 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.
Вывод команд с твоего последнего совета идентичен твоему.

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

Medievist
() автор топика
Ответ на: комментарий от fjoe

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

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

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

Medievist
() автор топика
Ответ на: комментарий от Medievist

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

Проблема была, как выяснилось, не в 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} - Так выдает ошибку
Просто я не хотел работать со Spamassassin-ом через Amavis, вот и замутил такую конструкцию, а SELinux-у она очень не понравилась.

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

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

Medievist
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.