Три ипостаси — FC17, dnsmasq и SELinux

Posted: 2012-11-10 in IT, Security
Метки:,

Тут снова про линукс. И немножко — про секас c dnsmasq, selinux и загрузкой по сети …

Сегодня решил обновить на основной машине операционку. Уж больно много всего интересного прикрутили в FC17.
Но поскольку до этого стояла FC14, то я решил сделать полный реинсталл с бэкапом конфигов — тупо быстрее и надежнее.
Как и полагается, система поставилась без проблем, Восстанавливаем конфиги из бэкапа, прописываем разделы в те же места, где они были раньше — и вообщем-то всё работает. Но без косяков естественно не обошлось.

Итак, обнаружилось ровно три заметных проблемы при апгрейде:
1). Переименованы сетевые интерфейсы. Сеть сама по себе конечно поднимется, но всякие сетевые хрени, к ней привязанные — надо переделать. В моем случае это был файервол, dnsmasq и виртуалки с сетевыми мостами.

2). iD пользователей теперь начинаются не с 500, а с 1000. Соответственно, если мы хотим, чтобы у нас отображался список пользователей — правим кусочки сбэкапленных passwd и group (прибавляем 500 к каждому iD), исправленное дописываем к уже существующим файлам. Ну и в shadow дописываем сбэкапленные хэши — чтобы не заводить пользователей заново. У меня конечно на домашней машине их всего 4, но самих-то паролей я от трех из них не помню =)
После чего с помощью

# find /home/user2 -exec chown user2:user2 {} ;

фиксим права доступа в домашнем каталоге каждому пользователю. Также пришлось пофиксить права в /var/www/html — у апача сменился iD пользователя.

3). Но самый разврат — это совокуплять SELinux-в-enforcing-режиме, dnsmasq и контекст безопасности для корня tftp-сервера. Если термин «SELinux» вам не знаком — то сперва имеет смысл узнать, что это за зверь такой.
Вообщем, симптомы такие — dnsmasq (нужный для работы сервера сетевой загрузки) не стартует из-за невозможности прочитать каталог /var/tftpd. Кстати, в FC17 добавили зачетную тулзу для мониторинга селинукса:

Тулза даже дает вполне толковые подсказки, как можно выйти из такой ситуации. Естественно, вариант «отключить селинукс» я не рассматриваю в принципе. Итак, сперва смотрим каталог по умолчанию для tftp-dnsmasq:

# cat /etc/dnsmasq.conf_DEFAULT | grep tftp-root=
#tftp-root=/var/ftpd

Епт. Это вообще не его каталог. Теперь посмотрим назначаемые контексты безопасности:

# semanage fcontext -l | grep /var/ftp
/var/ftp(/.*)?    all files  system_u:object_r:public_content_t:s0

public_content_t ?! Фу, гадость. Не, этот каталог мне может понадобится в будущем, да и TFTP и FTP — совершенно разные протоколы. Смотрим, нет ли в политиках путей именно для tftp:

# semanage fcontext -l | grep tftp
/etc/xinetd.d/tftp     regular file       system_u:object_r:tftpd_etc_t:s0
/tftpboot               directory          system_u:object_r:tftpdir_t:s0
/tftpboot/.*            all files          system_u:object_r:tftpdir_t:s0
/usr/sbin/atftpd        regular file       system_u:object_r:tftpd_exec_t:s0
/usr/sbin/in.tftpd     regular file       system_u:object_r:tftpd_exec_t:s0
/var/lib/tftpboot(/.*)? all files          system_u:object_r:tftpdir_rw_t:s0

Попробовал перенести корень tftp-сервера в /tftpboot, сделал restorecon — и фиг. Путей решений два, и оба предлагаются утилитой. Первый — сменить метку на каталоге, второй — прописать новый модуль политики с помощью audit2allow. Второй путь мне не нравится совершенно (не люблю сильно пилить системные конфиги), а первый — имеет по умолчанию другой контекст. Поэтому делаем мы вот так:

semanage fcontext -a -t dnsmasq_t -f -d '/var/tftpd'
semanage fcontext -a -t dnsmasq_t '/var/tftpd/.*'

Узнать, прописалось ли введенное в политику, можно вот такой комнадой:

 # semanage fcontext -l | grep /var/tftp
/var/tftpd    directory  system_u:object_r:dnsmasq_t:s0
/var/tftpd/*  all files  system_u:object_r:dnsmasq_t:s0

После чего делаем восстановление контекста безопасности:

restorecon -R /var/tftpd

Если система брыкается и матерится — пробуем повторить то же самое, переключив selinux в permissive, восстанавливаем контекст, проверяем, что он восстановился:

# ls -laZ /var/tftpd/
drwxr-xr-x. root nobody unconfined_u:object_r:dnsmasq_t:s0 .
drwxr-xr-x. root root   system_u:object_r:var_t:s0       ..
-rw-r--r--. root nobody unconfined_u:object_r:dnsmasq_t:s0 chain.c32
drwxr-xr-x. root nobody unconfined_u:object_r:dnsmasq_t:s0 livecd
-rw-r--r--. root nobody unconfined_u:object_r:dnsmasq_t:s0 memdisk
-rw-r--r--. root nobody unconfined_u:object_r:dnsmasq_t:s0 menu.c32
-rw-r--r--. root nobody unconfined_u:object_r:dnsmasq_t:s0 pxelinux.0
drwxr-xr-x. root nobody unconfined_u:object_r:dnsmasq_t:s0 pxelinux.cfg
-rw-r--r--. root nobody unconfined_u:object_r:dnsmasq_t:s0 reboot.c32
-rw-r--r--. root nobody unconfined_u:object_r:dnsmasq_t:s0 vesamenu.c32.

Как видим, нужный тип dnsmasq_t везде корректно прописался, можно снова переключить selinux в enforcing-режим. Вуаля, теперь dnsmasq корректно запустился в корреткном контексте:

# ps axfuZ | grep dnsmasq
system_u:system_r:dnsmasq_t:s0  nobody ... /usr/sbin/dnsmasq...

и загрузка по сети сразу стала работать.

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

Обсуждение закрыто.