Теперь, когда известно, как работает LIDS, и знакомы ее основные опции, нужно приступить к практической реализации LIDS в системе.

     Нужно помнить, что написание ACL для всей системы - очень трудоемкая задача, поэтому, как и в случае с iptables, рекомендуется создать shell-сценарий, содержащий директивы lidsconf. Первой директивой будет lidsconf -Z - эта директива удаляет все ранее существующие ACL. Этот сценарий надо поместить в /etc/lids, что сделает его невидимым за пределами LFS-сессии.

Защита системных программ.

     Какие же системные файлы и каталоги требуют защиты LIDS? Защищать надо содержимое каталогов /bin, /sbin, /lib, /usr/bin, /usr/lib и /usr/sbin. В эти каталоги производится установка программ и, если сделать их доступными только для чтения (RE­ADONLY), данное не позволит хакеру записать троянские версии системных программ.

     Также не надо забыватье защитить каталоги/usr/local/bin и /usr/local/lib, если придерживаться стратегии установки программ в каталог /usr/local. Конечно, при установке новой программы защита этих ката­логов может создать незначительные неудобства для администратора, но данное стоит того.

     Защита конфигурационных файлов /etc и /etc/shadow.

     Конфигурационные файлы - совершенно другая область защиты. Большая часть файлов в конкретном каталоге требует доступ в режиме «только чтение», поэтому надо прежде всего установить для всего каталога режим RE­ADONLY, а затем разрешить доступ в режиме WRITE к некоторым отде­льным файлам - глобально или для определенных субъектов.

     Наиболее важными файлами в каталоге /etc являются passwd/passwd-и shadow/shadow-: нужно запретить всем элементам доступ к файлам shadow/shadow- (DENY), кроме субъектов /bin/login, su и /usr/sbin/sshd - им полагается доступ READONLY.

     Нужно еще учесть утилиту /usr/bin/passwd. Ей нужен WRITE-доступ к файлу /etc/shadow, чтобы пользователь мог модифицировать свой пароль. Ког­да пользователь изменяет свой пароль, файл /etc/shadow создается зано­во, а не просто изменяется.

     В результате чего изменяется инод файла, а так как LIDS привязывается к инодам, то после изменения инода файла LIDS уже не будет защищать его - ведь нового инода нет в «базе данных» LIDS. Кроме данного, надо пре­доставить программе passwd WRITE-доступ ко всему каталогу /etc, пос­кольку запись файла - это изменение каталога. Если на месте passwd будет эксплоит хакера, данное приведет к тому, что он сможет получить доступ ко всем файлам в каталоге /etc.

     К сожалению, не существует простого способа решения данной проблемы: нужно употреблять альтернативную схему аутентификации, на­пример LDAP, чтобы запретить пользователям изменять свои пароли, или открыть WRITE-достуи к /etc. Существует, правда, еще один способ - самый безопасный, но очень неудобный для администратора.

     Нужно запретить WRITE-доступ к /etc, а, чтобы модифицировать свой пароль, пользователь должен будет обращаться непосредственно к администратору. Можно модифицировать пароль пользователя в LFS-сессии, заодно и проверить па­роль на «стойкость». Такой вариант приемлем, если пользователей не много - до 10 человек, учитывая то, что пароль они изменяют в кои веки раз, раз­дражать данное особо не будет. А вот если пользователей 200...

     Если гарантирование полной защиты каталога /etc слишком сложно, нужно обеспечить хотя бы защиту решающих файлов. Наиболее важ­ными являются каталоги:

     Возможности.

     Теперь можно перейти к файлу /etc/lids/lids.cap. Как уже было отмечено, следующие возможности должны быть запрещены:

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

     Определение требуемого доступа.

     Как определить, к каким файлам и каталогам надо обращаться тому или иному приложению? Отслеживать системные вызовы open(), chdir(), mk-dir() и др. - задача неблагодарная, но все же надо будет через данное пройти. Немного облегчить задачу позволяет LIDS-FAQ, расположенный по адресу: http://www.lids.org/fids-faaq/lids-faq.html. В ней можно найти ACL для разных приложений: login, su, MySQL, BIND, OpenSSH, Apache и др.

     При самостоятельной разработке ACL для приложения, ACL которого нет в LIDS-FAQ, последовательность создания ACL следующая:

     Проверить ACL просто - нужно запустить приложение при включенной защите LIDS. Если что-то пойдет не так, в /var/log/messages можно найти соот­ветствующее сообщение LIDS.