Рассмотрим пример ACL, который позволяет работать DNS-серверу на машине. ACL будет состоять из двух частей. Первая часть будет содержать общий набор правил, предоставляющих базовый доступ. Эта часть универсальна - она подойдет не только для DNS-сервера, но и для разных остальных приложений, запущенных в Linux-системе.

     Во второй части будут описаны специфические для DNS-сервера правила, ограничивающие доступ к файлам, и определяющие возможности DNS-сервера. Как было написано ранее, набор правил будет представлен в виде shell-сценария, который содержит серию команд lidsconf.

     Сначала надо сделать системные исполнимые файлы и библиотеки доступными только для чтения. Обойти данное ограничение нужно только в LFS-оболочке. Итак, надо защитить каталоги /bin, /sbin, /usr и /opt:

     Элемент не определен, поэтому определенные объекты будут общедоступны только для чтения всем процессам в системе. Нужно помнить, что ACL наследуется, то есть доступ READONLY получат все подкаталоги указанных каталогов. Тоже следует помнить, что наследование не распространяется на подмонтированные файловые системы. К примеру, если к /usr/local подмонтирован другой раздел, то правила, примененные к /usr, не будут распространяться на файлы и каталоги, находящиеся в другом разделе.

     Кроме этих каталогов, надо защитить каталоги /etc и на /boot. Однако предоставление READONLY-доступа к каталогу /etc изрядно проблематично, поэтому нужно сосредоточиться на защите решающих файлов данного каталога.

     Наибольший интерес для хакера являют именно данные фай­лы. К примеру, файл /etc/exports определяет экспортируемые файловые системы, а изменение файла /etc/resolv.conf может перенаправить за­просы нашего резолвера на свой DNS-сервер, который будет предоставлять неправильную информацию.

     В зависимости от установленных в системе пакетов, возможно, придется добавить другие файлы в этот список. Были описаны наиболее критичные файлы.

     Тоже не надо забывать про файлы журналов, находящиеся в каталоге /var/log. Для большинства файлов нужно установить режим APPEND, и только для некоторых из них - режим WRITE, но только для определенных субъектов (login, init и halt):

     Благодаря этим ограничениям, крекер, получивший root-доступ, не сможет отредактировать данные файлы, чтобы скрыть свое фигурирование. Не­достаток данного метода заключается в том, что утилита logrotate не сможет больше функционировать, но всему есть своя стоимость. Теперь за «уборку» жур­налов нужно отвечать самому.

     Чтобы logrotate работала, ей можно предоставить WRITE-доступ ко всему каталогу /var/log, но не рекомендуется данное воплощать, потому что крекер может запустить logrotate много раз подряд - до тех пор, пока из журнала не удалятся следы его присутствия. Рекомендуется отключить logrotate и «чистить»журналы вручную. Во многих системах logrotate вы­зывается демоном cron. Чтобы данного не происходило, надо удалить файл /etc/cron.daily/logrotate или закомментировать его содержимое.

     Можно определить, как named вза­имодействует с системой - нужно предугадать все файлы, к которым понадобится доступ приложению, и определить возможности для приложения. Поначалу можно запретить доступ ко всей файловой системе:

     BIND должен получить доступ к файлу конфигурации (/etc/named. conf) и к файлам зоны (каталог /var/named):

     Как и какой угодно другой демон, named протоколирует свой PID в файл, располо­женный в каталоге /var/run. Обычно этот файл называется /var/run/named.pid. Нужно разрешить приложению создавать файл с таким именем:

     На данный момент разобранны все файлы, которые необходимы демону named. Теперь можно определить, какие ему желательны библиотеки. Для данного можно употреблять программу strace, которая покажет все сис­темные вызовы, а наряду с ними и все внешние файлы. Опция -f не позволя­ет приложению перейти в фон:

     Вывод программы named будет записан в файл namedtrace. Демон named должен поработать несколько часов, после данного нужно завершить процесс (named, а не strace!) и проанализировать файл named trace:

     Эта команда выведет все вызовы open() - можно увидеть не только все файлы, которые используются приложением, но и режимы, в которых они используются. На основании данного списка можно составить такой список правил LIDS:

     Этот список правил несколько упрощен, так как named использует много библиотек в /usr/lib и /lib, но проще предоставить READ-доступ к этим каталогам, чем прописывать отдельно каждую библиотеку.

     Теперь пришла очередь установки возможностей. Сперва нужно разрешить named привязываться к порту 53:

     При запуске named с опцией -u <имя пользователя> он снижает свои привилегии до уровня обычного пользователя, указанного с помощью опции -u. Поэтому надо разрешить ему производить вызовы SUID и SGID:

     Если BIND запускается в chroot-окружении, можно установить возмож­ность CAP_SYS__CHROOT:

     Как и у Apache, у BIND может быть несколько потомков, которым будет ну­жен доступ ко всем файлам и возможностям, описанным ранее, поэтому для переноса возможностей другим процессам можно разрешить возможность CAP_SYETPCAP:

     Теперь самое время протестировать созданный ACL. Запустите named и следите за системными журналами - в них можно найти сообщения об ошибках, если что-то пойдет не так.

     В оканчание можно сказать, что, если возникли проблемы с тем или иным сервисом, можно посетить http://www.lids.org - там можно найти много уже готовых ACL для различных сервисов.