Не люблю я этот selinux..

[dil]

Вчера поставил на очередную машинку с CentOS zabbix’овского клиента, добавил ту машинку на сервер, всё настроил, бОльшая часть данных на сервер успешно приходила, а вот про MySQL почему-то нет..

Показывало такую ошибку:
"Received value [ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13)] is not suitable for value type [Numeric (float)]"

Попробовал на самой машинке – всё работает:

# zabbix_agentd -t mysql.status[Bytes_sent]
mysql.status[Bytes_sent]                      [t|59709]
# zabbix_agentd -t mysql.slave[Seconds_Behind_Master]
mysql.slave[Seconds_Behind_Master]            [t|166]

А когда то же самое запрашивается с сервера, то фиг:

# zabbix_get -s 10.18.19.100 -k 'mysql.status[Bytes_sent]'
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13)

Коллеги порекомендовали посмотреть в /var/log/audit/audit.log, и оказалось, что mysql, запускаемый из-под заббикса, почему-то не может ни прочитать .my.cnf, который я для него создал, ни вообще подключиться к mysql’ному серверу через местный socket..

type=AVC msg=audit(1509982155.365:26576): avc:  denied  { read } for  pid=6599 comm="mysql" name="my.cnf" dev="dm-0" ino=166 scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:object_r:mysqld_etc_t:s0 tclass=file
type=AVC msg=audit(1509982155.366:26577): avc:  denied  { read } for  pid=6599 comm="mysql" name=".my.cnf" dev="dm-7" ino=3148594 scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file
type=AVC msg=audit(1509982155.368:26578): avc:  denied  { connectto } for  pid=6599 comm="mysql" path="/storage-mysql/mysql/mysql.sock" scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:system_r:mysqld_t:s0 tclass=unix_stream_socket

Оказалось, что это selinux не разрешает. Выключил его нафиг, и всё заработало.
Но коллеги сказали, что не положено selinux выключать, так что пришлось его обратно включить, опять перестало работать.

Посоветовали вытащить из лога то, что заббиксу не разрешалось:

#grep "denied.*zabbix_agent" /var/log/audit/audit.log | audit2allow -M zabbix_agent

и всё это явно разрешить:

#semodule -i zabbix_agent.pp

Попробовал, а нифига не поменялось. Ещё раз попробовал, посмотрел, что в этом .pp написано, а всё равно не помогло.
И только после третьего раза заработало, как надо.. Такие вот загадочные грабельки, как обычно.

Оригинал этой записи в личном блоге.

Comments

[pan_2]

Policy у SELinux страшны и убоги, но вполне с ними можно жить.

[dil]

А нафига этот selinux вообще нужен?

[pan_2]

Для того же, для чего UAC в Виндах используется - чтобы если даже через дырку заползли в исполняющийся код демона - всё равно нихера не могли за его пределы вырваться, потому что система демону не даёт делать (вне зависимости, легитимно или нет) ничего за пределами выданных контекстов.

[dil]

Ну вот когда программа, запушенная юзером, не может залезть в чужие файлы - это ещё логично, а когда в свои собственные - это уже бред.

mysql же это не демон, это клиентская программа, которая по умолчанию лезет в ~/.my.cnf.
Так что ж, теперь для каждой программы надо явно указывать, в какие файлы ей можно залезать? Это ж замучаешься, чтоб система хоть как-то более-менее нормально работала.

[pan_2]

>>Так что ж, теперь для каждой программы надо явно указывать, в какие файлы ей можно залезать?
А почему нет? Для того же mc это будет жопа, но зачем mysql лезть в файлы bind'а? Зачем bind'у лезть в файлы PAM? Если речь идёт о _сервисах_ - ограничение контекстом - единственный реализуемый вариант без выкидывания в песочницу.

[dil]

Ну это да, а вот когда mysql'ному клиенту не дают залезть в его собственный my.cnf - это ненормально.

[pan_2]

ну тут есть нюансы:
твой мускуль, если я правильно понял - запускался от имени заббикса, так что и _контекст_ выполнения имел заббиксовый, а не мускульный. Т.е. то, что твой заббикс не мог подцепить сокет мускуля - всего лишь частный случай "не пойми кто лезет не пойми куда", поэтому и СЕЛинуск его и послал в баню.

По поводу "В таком случае имеет смысл определённым программам запретить определённые доступы" - это вариант чёрного списка, и это будет обречено на провал.
Допустим, твоему заббиксу надо как раз запретить лазить в мускуль (ну например он у тебя убер секурный, что даже группа мониторинга не может туда смотреть).
И ты запрещаешь доступ ему в /var/mysql/mysql.sock. Вроде бы всё хорошо? Ан нет, в твоём собственном примере, сокет лежит по адресу /storage-mysql/mysql/mysql.sock - всё, твой чёрный список оказался бесполезен.

[dil]

Но когда заббикс запускал mysql'ный клиент, почему ему не давали собственный my.cnf прочитать?

mysql.sock - это уже другое дело. Если руками запрещать, то, естественно, надо указывать не дефолтовый адрес, а тот, где он на самом деле используется.

[pan_2]

Потому что scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:object_r:mysqld_etc_t:s0

Т.е. контексту исполнения zabbix_agent не было выдано право обращаться к контексту доступа mysqld_etc.

Касаемо >>почему ему не давали собственный %anyfile% прочитать
повторюсь: SELinux был разработан для того, чтобы иметь возможность более гранулярного управления выдачи _возможностей_ для работающих процессов.
Стандартные unix permissions этого не обеспечивают совершенно даже для файлого доступа, и совершенно невозможно их использовать для разграничения доступа к не файловым объектам (см. тот же пример про apache и возможность им ходить по SMTP).

[pan_2]

О, для понимания - зайдём с другой стороны.
Дано:
lAMP, в лампе крутится php которому можно ходить на SMB, но совершенно не нужно отсылать по SMTP, а вне лампы крутится какой-нить мониторинг, который как раз по SMTP шлёт письма.
Задача - стандартными средствами не дать возможности php стать почтовым ботом.

[dil]

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

[bond_jimme]

>scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=system_u:object_r:mysqld_etc_t

Надо смотреть вживую, но, похоже, были проблемы с контекстами на файлах и сокете.

[dil]

Не понял. Что такое "контексты" на файлах и сокете??

[bond_jimme]

[dil]

А при чём тут /etc/my.cnf? Такого вовсе нету, только /etc/mysql/my.cnf
Да и всё равно он читабельный всеми юзерами.

А .my.cnf лежал в ~zabbix/, владелец и группа - zabbix.

И почему mysql, запущенный zabbix'ом, не мог прочитать эти файлы??

[bond_jimme]

>А при чём тут /etc/my.cnf? Такого вовсе нету, только /etc/mysql/my.cnf
Я привел свой в качестве примера: показать, что такое контексты SELinux.

>Да и всё равно он читабельный всеми юзерами.
Это если все остальное отключено. А так еще могут быть ACL и SELinux, которые влияют на доступ к файлам (и другим объектам типа сокетов или портов в случае последнего).

>И почему mysql, запущенный zabbix'ом, не мог прочитать эти файлы??
Как уже выше написал, судя по сообщеням в audit.log, на нужном my.cnf были настроены неверные контексты, поэтому SELinux не давал работать mysql-ю с данным файлом. По идее, "chcon -t mysqld_etc_t my.cnf" должно было помочь.


Насколько помню (редко пользуюсь данной утилитой), audit2allow генерирует два файла: в одном - апдейт политик SELinux, а во втором - описание, что за проблемы.


PS: На работе Windows-админы часто правят зоны в Bind с использованием миднайткоммандера. Он перезаписывает файл зоны с такими же правами, но с пользовательскими контекстами SELinux. После этого Bind отказывается запускаться, так как не может прочитать данный файл. Проблема с MySQL примерно такого же плана.