informacionnaya_bezopasnost

В этой статье курса «Linux для начинающих» мы рассмотрим ещё один способ защиты вашей системы, который с одной стороны повышает безопасность,  а с другой стороны может доставить лишние неудобства. Система Linux может работать кхм… не совсем стабильно, а точнее многое может не работать в том или ином случае, если не знать, что же это за пакет такой SELinux, и с чем его едят.

Все мы привыкли, что Linux защищает свои файлы от посягательств путём выставления прав на папки и файлы (chmod), а также назначением хозяина (chown), т.е. распределяем права между пользователями (кто имеет право запускать, читать, удалять, модифицировать файлы,  и от чьего имени тот или иной демон должен стартовать в системе).  При том пользователем может быть вовсе не человек, но это отдельная история… А сейчас мы поговорим как раз о тех случаях, когда в Linux работают несколько пользователей (т.е. реальных людей), и казалось бы, что все права разделены чётко, и тем, у кого много полномочий, не взбредёт вдруг в голову переместить\удалить нужные для стабильной работы ОС Linux файлы. Но ведь и так бывает? А что, если вдруг тот или иной демон был установлен из недоверенного источника (ну ведь бывает, правда? Улыбаюсь) и демон этот оказался.. кхм… ну допустим есть ошибки в коде, которые приводят к переполнению буфера, или точно известно, что конкретный демон должен использовать для своей работы три конкретных конфигурационных файла, а этот «нехороший» демон пытается использовать какой-то «левый» скрипт? Вроде с виду всё работает, а при этом в дополнение к нужному демону в системе работает злобный скрипт… Как обезопаситься?

 

Вот для этого и был придуман SELinux.

Принцип работы:

SELinux реализует так называемый «Мандатный контроль доступа» (mandatory access controls -MAC). При мандатном контроле доступа пользователи не имеют официального права управлять доступом к объектам. Вместо этого, администратор определяет общесистемные политики доступа. Хорошо реализованная политика действует по принципу «наименьшего уровня привилегий», т.е. разрешении доступа только тогда, когда это реально необходимо.

Разработка политик это отдельная и непростая тема. Существуют целые курсы по политикам SELinux. Например, для защиты нового демона, в политике должны быть перечислены ВСЕ файлы, каталоги и любые другие объекты, к которым данный демон должен иметь доступ. В случае со сложным софтом, как например sendmail или Apache-демон httpd, сделать это будет весьма и весьма непросто. Многие общие политики доступны в сети Internet. Они легко устанавливаются и конфигурируются. Существуют даже полнофункциональные редакторы, упрощающие работу.

Конфигурирование:

Рассмотрим основы конфигурирования пакета SELinux. Конфигурация SELinux содержится в файле/etc/selinux/config.  И в этом файле есть две интересные строки:

SELINUX=enforcing

SELINUX=targeted

Первая строка может иметь три значения: enforcing, permissive или disabled. Значение enforcingприменяет загруженную политику и предотвращает попытки её нарушения. При значении permissiveпопытки нарушения допускаются, но при этом регистрируются в системе SysLog. Ну и как вы уже догадались, значение disabled вовсе отключает SELinux.

В строке SELINUXTYPE указывается тип переменной политики. В Red Hat и Fedora используются политики двух типов: политика targeted (целевая), которая нацелена на защиту предопределённых демонов (httpd, dhcpd, mailman, named, portmap, nscd, ntpd, mysqld, postgres, squid, winbindd и  ypbind.); политика strict подразумевает защиту ВСЕЙ системы. Хотя эта политика и доступна, Red Hat её не поддерживает, потому что ограничения являются настолько жёсткими, что системой становится очень трудно пользоваться. Получается, что политика targeted наиболее удобная, нацелена на конкретные файлы и (теоретически) не должна влиять на общее удобство использования системы. Но не всё так просто… При наличии проблем с новым ПО нужно проверить лог файл (/var/log/messages) на наличие ошибок SELinux.

На написание это статьи меня сподвиг один из случаев в моей практике, когда пришлось восстанавливать работу веб-сервера, базирующегося на CentOS. После сбоев был переустановлен mysql-server, но демон (mysqld) не хотел запускаться, то ругаясь на access denied (несмотря на то, что всё было ровно как в плане chmod, так и в chown),то матерясь на то, что в упор не видит сокета. Дело оказалось в недоверии SELinux к демону mysqld. Конечно же были изменены политики и проблема решена... но, извиняюсь, пока допёрло, уже и рак мог просвистеть… так что имейте ввиду. Ситуацию усугублял ещё и тот факт, что сервер поднимался и администрировался не мной, и упал он тоже не при мне, и восстанавливать изначально пытался не я, а, как говорится «чужой сервак – потёмки» J. До сих пор неизвестно как именно всё изначально было сломано, и как пытались восстановить до меня. А что касается SELinux, то я просто раньше не заморачивался. Ранее конечно попадались упоминания об этом пакете, но всё как-то краем проходило. Многие вообще стараются по возможности его отключить (disabled, помните? J), но нужно иметь ввиду… Кстати, когда читал логи о невозможности запуска mysqld, то там не было ни слова о SELinux, а ведь это могло бы натолкнуть на определённые мысли, или помочь при «гуглении на тему».  Я конечно ни в коем разе не хочу как-то намекнуть на ненужность данного пакета. SELinux нужен, но только в том случае, если вы реально хотите с ним заморачиваться и обезопасить систему по максимуму. И ещё… прошу меня простить за «многа букав», просто, как показывает практика, повествовательный режим улучшает восприятие и помогает лучше запоминать материал… надеюсь вам понравилось Улыбаюсь

Краткая историческая справка:

SELinux – это проект Агентства национальной безопасности США, который свободно распространяется с конца 2000г. Он был интегрирован в ядра Linux серии 2.6. Однако отдельными дистрибутивами он адаптируется вяло, за исключением разве что таких дистрибутивов как Red Hat Enterprise Linux и Fedora.

SELinux присутствует в дистрибутиве Red Hat Enterprise Linux начиная с версии 4, а в Fedora с версии Core2. Стандартная установка Fedora и RHEL предполагает активизацию некоторых защитных политик SELinux с самого начала. Пакетами SELinux для Debian и Ubuntu занимается некий Рассел Коукер, сотрудник Red Hat, создавший политики strict и targeted.

В OpenSuSE применяется её собственная реализация мандатного доступа MAC, которая называется AppArmor и НЕ включает SELinux.

adminC чего начать?ПрограммыСтатьиAppArmor,Fedora,RedHat,SELinux,Безопасность,Программы,Установка
В этой статье курса «Linux для начинающих» мы рассмотрим ещё один способ защиты вашей системы, который с одной стороны повышает безопасность,  а с другой стороны может доставить лишние неудобства. Система Linux может работать кхм… не совсем стабильно, а точнее многое может не работать в том или ином случае, если...