LXF93:SELinux
|
|
|
Содержание |
Доступно о SELinux
Вы запросто достигнете безопасности правительственного уровня, если у вас хватит терпения постигнуть ее суть. Пол Хадсон упростит эту задачу...
Red Hat Enterprise Linux 5 выпущен, и, как и следовало ожидать, многие в восторге от интегрированной виртуализации Xen. Но в недрах системы скрыта другая, столь же продвинутая технология, о которой вы наверняка уже слышали: Security Enhanced Linux, или, сокращенно, SELinux. Подобно драйверу звуковой карты или OpenOffice.org, SELinux – один из тех компонентов Open Source, о которых никто даже не задумывается: он работает в фоновом режиме, и вы вспоминаете о нем, только когда возникают проблемы.
В ранних дистрибутивах, содержащих SELinux, например, Fedora Core 6, SELinux был скорее помехой, чем подмогой, и его норовили отключить, поскольку он осложнял повседневную работу настольного ПК. Но RHEL 5 включает свежую версию SELinux, которая, сохранив исходный принцип SELinux, обзавелась множеством инструментов, упрощающих понимание ее установки и использования. В нашей статье мы познакомим вас с возможностями SELinux и покажем, как освоиться с ним в RHEL 5. Мы использовали свежую инсталляцию RHEL 5, прихватив дополнительный пакет Web Server, чтобы использовать Apache для теста на выживаемость. CentOS 5 – фактически RHEL 5, только без товарного знака – тоже включает поддержку SELinux, а еще вы сможете следовать большей части нашего урока на Fedora Core 7. Технологии, описанные здесь, применимы и для других сетевых демонов.
Безопасный по умолчанию
SELinux был изобретен в Национальном Агентстве безопасности США для удовлетворения потребности в... впрочем, вам, наверное, неинтересна история SELinux и всякая ерунда. Лучше мы вам покажем, как SELinux защищает вас 24 часа в сутки, 7 дней в неделю, независимо от того, осознаете вы это или нет. Откройте терминал, введите
su - vim index.html
затем для перехода в режим вставки нажмите i и введите:
Hello, world!
Для сохранения файла нажмите Escape, затем введите :wq. Вы должны снова очутиться в командной строке [вы также можете использовать любой другой привычный вам редактор, – прим. ред.]. Теперь выполните следующие две команды:
Apachectl start mv index.html /var/www/html
Это вполне обычная штука: мы создали HTML-файл с некоторым содержимым, запустили Apache, затем скопировали новый файл в каталог, который используется Apache для обслуживания web-страниц. Но сейчас вы увидите, насколько педантично печется SELinux о вашей безопасности! Попробуйте запустить Firefox и указать ему адрес http://localhost , чтобы он запросил данные с локального сервера Apache. Вместо того, чтобы увидеть 'Hello, world!' вашего index.html, вы увидите приветственную страницу Red Hat, установленную по умолчанию. Пока вы оправляетесь от секундного замешательства, в правом верхнем углу экрана появится пузырик с сообщением: 'SELinux: AVC denial, click icon to view.' [Запрет AVC, щелкните на иконке для просмотра.]
Если 'AVC' для вас пустой звук (оно расшифровывается как Access Vector Cache, хотя от этого вам вряд ли полегчало), то слово 'denial' уже намекает на происшедшее: когда вы пытались загрузить страницу с Apache, Apache проверил, можно ли ему читать этот файл, и получил отказ от SELinux. Однако вернувшись к вашему окну терминала и выполнив ls -l в /var/www/html, вы увидите, что файл имеет флаги разрешения -rw-r--r--, то есть доступен всем пользователям. И что это даст? Щелкнув по значку, запустим Setroubleshooter, новую утилиту, предназначенную для перевода практически невразумительных сообщениях об ошибках SELinux на язык, понятный простым смертным.
В нашем случае вы увидите вверху сообщение, а внизу – его объяснение. Сводка должна звучать примерно так: 'SELinux пресек обращение пользователя /usr/sbin/httpd к файлу с потенциально неверным маркером (/var/www/html/index.html)'. Вам, может быть, это ничего не говорит, однако прокрутив информационную панель донизу, вы найдете нечто более осмысленное по сравнению с «сырым» сообщением аудита:
avc: denied { getattr } for comm="httpd" dev=dm-0 egid=48 euid=48
exe="/usr/sbin/httpd" exit=- 13 fsgid=48 fsuid=48 gid=48 items=0
name="index.html" path="/var/www/html/index.html" pid=2877
scontext=user_u:system_r:httpd_t:s0 sgid=48 subj=user_u:system_r:
httpd_t:s0 suid=48 tclass=file tcontext=user_u:object_r:user_home_t:s0
tty=(none) uid=48
И сырое сообщение, и аккуратно разобранная версия Setroubleshooter советуют нам обратить внимание на контекст, так как для SELinux все – и процессы, и файлы – имеет 'контекст' безопасности, используемый как маркер. К счастью, Setroubleshooter сумел опознать данную конкретную проблему и говорит, что использование mv для копирования файлов (что мы пытались сделать после Hello World!) часто вызывает проблемы, поскольку не меняет контекст безопасности источника.
Иными словами, проблема такова: SELinux полагает, что файлы из нашего домашнего каталога не должны обслуживаться в качестве web-страниц – и правильно полагает: если вдруг ваш сервер Apache будет взломан, вы не захотите, чтобы ваши личные файлы были доступны всему миру. Вот это и обеспечивает SELinux, последняя линия обороны вашего сервера: у вас все-таки есть возможность выжить, даже если в вашу систему засадили удаленный эксплойт.
Опция контекста -Z
Если SELinux основывается на контекстах безопасности файлов и процессов, как мы можем узнать, что это за контексты? Более того, как можно их поменять? Оказывается, существует универсальная опция, дополняющая приложения командной строки, и она выдает контекстную информацию. Назовем ее опцией контекста, поскольку все приложения, используемые вами – ps, ls, и т.п. – имеют эту специальную опцию -Z для вывода контекстной информации. Обратите внимание, что здесь используется именно заглавная Z – к ней сложно подобрать смысл, и, видимо, именно поэтому она годится для всех приложений! Используя -Z, можно извлекать контекстную информацию различных объектов. Например, перейдите в каталог /var/www и выполните ls -Z. Вы увидите следующее:
[paul@localhost www]$ ls -Z drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t cgi-bin drwxr- xr-x root root system_u:object_r:httpd_sys_content_t error drwxr-xr-x root root system_u:object_r:httpd_sys_content_t html drwxr-xr-x root root system_u:object_r:httpd_sys_content_t icons drwxr-xr-x root root system_u:object_r:httpd_sys_content_t manual drwxr-xr-x webalizer root system_u:object_r:httpd_sys_content_t usage
А если вы сделаете то же в каталоге /var/www/html, вы увидите вот это:
-rw-r--r-- root root user_u:object_r:user_home_t index.html
Контекст user_home_t сообщает, что index.html принадлежит домашнему каталогу пользователя, а это значит, что Apache не будет его обслуживать. Взамен ему следует иметь контекст httpd_sys_content_t, то есть контекст по умолчанию для /var/www/html. В этом – основное отличие mv от cp: mv перемещает файлы, и они сохраняют свой прежний контекст; cp создает новый файл, и он наследует права доступа каталога назначения.
Горю можно помочь, присвоив файлу index.html контекст httpd_ sys_content_t командой chcon, примерно так:
chcon -t httpd_sys_content_t /var/www/html/index.html
Параметр -t указывает тип httpd_sys_content_t, так что, введя ls -l , вы увидите следующее:
-rw-r--r-- root root user_u:object_r:httpd_sys_content_t index.html
Если Firefox у вас все еще запущен, убедитесь, что сейчас доступ к index.html уже имеется, поскольку SELinux не против, чтобы Apache читал принадлежащее ему содержимое. Если нужно изменить несколько файлов, chcon используется так же, как chmod: укажите несколько имен файлов и примените регулярное выражение наподобие index.* или параметр -R обработки вложенных каталогов.
Программа restorecon пользуется тем, что SELinux считает файлы в /var/www имеющими контекст httpd_sys_content_t, и может скопом поменять их контекст на принятый для данного каталога по умолчанию. Например, следующая команда присвоит всем файлам в каталоге /var/www/html контекст httpd_sys_content_t, заходя внутрь подкаталогов (опция -R) и выводя имена файлов, подвергшихся изменениям (-v):
restorecon -v -R /var/www/
Проверить контекст по умолчанию для других файлов можно командой
semanage fcontext -l
SELinux использует регулярные выражения как шаблон имен файлов. Например, правило, с которым мы работали до сих пор, выглядит как
/var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
Опцию -Z можно использовать где-нибудь еще, например, с командой ps. Выполнив ее, вы заметите, что большая часть запущенных в вашей системе приложений выполняется с контекстом unconfined_t. Исключения - GDM, X, Sendmail, cupsd и различные сетевые службы, плюс некоторые ключевые службы, важные для функционирования системы. Это потому, что большинство запускаемых вами приложений используют ваш уровень привилегий, то есть смогут влиять только на файлы с тем же Unix-уровнем доступа, равно как и с тем же контекстом SELinux.
Контроль доступа к порту
Мы увидели, как SELinux защищает ваши файлы, но он также защищает вашу сеть путем ограничения числа портов, к которым может обращаться сетевой демон. Полный список ограничений на порты можно получить по команде
semanage port -l
Все, что не попало в выведенный список, можно классифицировать следующим способом: если это 1023 или меньше, порт классифицируется как reserved_port_t; иначе он относится к port_t. Вы должны увидеть в списке также и http_port_t; если нет, попробуйте отфильтровать список с помощью semanage port -l | grep http. SELinux дозволяет Apache выполняться только на HTTP-портах, то есть разрешены порты 80, 443 и прочие. Если Apache попытается обслужить страницы через другой порт - даже разрешенный в обычном режиме, будучи больше, чем 1023 - SELinux отловит это и пресечет.
Давайте проверим это примером из реальной жизни. Пусть кому-то удалось перенастроить Apache, и он стартует с порта 3306, а не с 80. А 3306 - это порт MySQL, то есть вполне законный порт для соединения с сервером. Мы можем имитировать такую ситуацию, подредактировав файл /etc/httpd/conf/httpd.conf и изменив следующую строку:
Listen 80
Вместо 80 поставьте там 3306. Сохраните файл и перезапустите Apache командой apachectl restart. Как и ранее, будет задержка на пару секунд перед тем, как всплывет пузырь запрета AVC: SELinux недоволен тем, что Apache хочет занять порт MySQL, и совершенно правильно говорит, что это, быть может, сигнал о попытке вторжения.
Помните, что для прочной безопасности сети главное - держать глубокую оборону: можно иметь брандмауэр по периметру сети, плюс другой, запущенный на ваших индивидуальных серверах; и, конечно же, права доступа системы Unix остановят множество проблем. Однако наличие SELinux в этой смеси добавит еще один уровень надежности и сможет пресечь на корню опасный взлом, упущенный другими. Не верите нам - послушайте Марка Кокса [Mark Cox] из команды безопасности Red Hat: «Мы включили SELinux в установку по умолчанию не без причины; не отключайте ее! В 2005 году червь Linux/Lupper использовал дыры в некоторых PHP-приложениях. Политики SELinux, установленные по умолчанию на Red Hat и Fedora, блокировали этого червя.»
Взгляд с высоты
Сейчас, когда вы имеете представление о методах фоновой работы SELinux, мы познакомим вас с командой system-config-selinux, известной также как SELinux Management Tool (SMT). Вы сможете найти его в пункте меню System > Administration > SELinux Management. Хотя она и скрывает сложности SELinux за удобным интерфейсом, работать с ней следует осторожно, так как любые сделанные вами изменения тут же вступают в силу. Существует два важнейших подводных камня:
1 Отсутствует опция отката (undo); большинство действий применяется немедленно, так что не щелкайте где ни попадя, чтобы просто «посмотреть, что будет».
2 SELinux требует времени для обработки ваших изменений, и обычно между щелчком по флажку и появлением галочки проходит несколько секунд. Если вы поторопитесь щелкнуть снова, вы попросту отмените первый щелчок, и в итоге вся операция займет еще больше времени.
Два главных раздела SMT - Boolean и File Labelling. Первый имеет набор опций, которые либо активны, либо нет, согласно установке флажка. Опции довольно обширны, и нередко способны полностью отключить SELinux для конкретной службы. Если вы затрудняетесь в устранении возникшей неисправности, то это и вправду может оказаться единственным подходящим решением.
Раздел File Labelling - графическая версия команды semanage fcontext -l, которую мы уже выполняли. Она отображает все автоматически определенные контексты для файлов и позволяет создавать новые. Но поскольку здесь доступны регулярные выражения, File Labelling полезнее банального «справочника»: вы можете видеть, как именно restorecon будет обрабатывать данный каталог. Опять-таки, будьте внимательны при работе с этими настройками: некоторые из них, например, перемаркировка файловой системы, занимают очень много времени, и даже могут повредить вашу систему.
И все это о контекстах
Хотя мы лишь бегло коснулись SELinux на этих нескольких страницах, надеемся, что ключевые моменты донесены до читателя:
1 По умолчанию SELinux включен, и пусть будет включен, если только из-за него не возникло серьезных проблем.
2 SELinux много сильнее, чем простая защита файлов от чтения. Процесс, защищенный SELinux, повязан по рукам и ногам, и даже будучи взломанным, не в силах причинить вреда.
3 Безопасность SELinux расположена над стандартной безопасностью Unix, так что, столкнувшись с проблемами, взгляните на контекст безопасности файла, пользователя и процесса.
4 SELinux Troubleshooter - самый простой способ понять сообщения AVC-запрета SELinux, и часто оттуда можно извлечь совет, как исправить проблему.
Но, возможно, самое главное вот что: SELinux -дополнительный инструмент безопасности вашего компьютера, и он работает совместно с брандмауэрами и стандартной безопасностью Unix. Он не сделает вашу систему неуязвимой, но действительно является свободным и достойным подспорьем существующих средств безопасности.
Врезки
SELinux до Unix
SELinux не может разрешить то, что запрещают стандартные права доступа Unix. Например, если файл index.html с которым мы работали в этой статье, имеет правильный контекст SELinux для чтения демоном Apache, но не имеет прав доступа Unix на чтение для пользователя, от имени которого работает Apache, ничего не получится. SELinux служит для дополнения прав доступа Unix, а не для их отмены!
SELinux против AppArmor
SELinux часто критикуют за то, что, в отличие от AppArmor (система безопасности Novell, приписывающая профили различным программам), здесь не используется режим обучения для выяснения настроек требуемых для правильной работы системы. Например, для настройки в AppArmor вашего сервера Apache вам просто следует поместить его в режим наблюдения, затем загрузить все страницы (и, в частности, все исполняемые скрипты), и он вам покажет, в какой степени сервер требует доступа к машине.
Однако способ, применяемый AppArmor, имеет недостаток: AppArmor полагает, будто вам лучше знать, что безопасно для вашего сервера, а что нет. Вам не составит труда обучить его дурному поведению, и тогда он уже не станет извещать вас о проблемах. Например, если ваш сервер настроен небезопасно, но вы заявили AppArmor, что это - штатное поведение, не видать вам потом предупреждений.
В случае с SELinux, Red Hat обеспечивает предустановленный набор правил для всех общепринятых сервисов, гарантирующих, что вы в безопасности уже по умолчанию. Имеется специальная утилита под названием audit2allow, позволяющая создать правила на основе AVC-запретов.
Говорит Дэн Уолш
Совет от главы проекта SELinux.
«Подгружаемые модули политики позволяют администраторам легко изменять политику SELinux для их системы. SELinux иногда отказывает в доступе к ограниченному домену, а администратор считает, что зря, или, как часто бывает, просто хочет поработать. Например, политика не позволяет выполняться демону Avahi, поскольку ему требуются способности, о которых автор политики не знал. Для постройки и установки модуля политики администратор может использовать утилиту audit2allow. Чтобы изменить политику SELinux на своих машинах, можно выполнить следующие команды:
# grep avahi /var/log/audit/audit.log | audit2allow -M myavahi # semodule -i myavahi.pp
Политика будет изменена и останется в силе даже после перезагрузки, а также при последующих обновлениях. Разумеется, администратору следует сообщить о недочете автору политики.»
Вести с полей
Мы попросили двух экспертов SELinux дать лучшие советы для новых пользователей SELinux.
«Некоторые пользователи SELinux стараются узнать о нем как можно меньше. Подход "Подавлять-предупреждающие-сообщения" может привести к ненадежности системы, ошибочно расцениваемой как надежная. А это - наихудшее состояние системы, куда хуже, чем просто ненадежная система, которая известна как надежная. Не следуйте по этому пути.»
Билл Маккарти [Bill McCarty], автор SELinux ((O’Reilly, 2004)
«Прежде чем дать права доступа домену, следует немного подумать. Простая прогонка сообщений об отказе через audit2allow часто приводит к чрезмерно попустительской политике. Добавляйте только те разрешения, которые считаете действительно необходимыми, и обязательно затем проверяйте, работает ли приложение правильно. Используйте dontaudit для прав доступа, которые не нужны домену.» Дэвид Капланко [David Caplanco], соавтор SELinux By Example (Prentice Hall, 2007)
