Контрольная сумма на защите Linux/FreeBSD

 СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС

Контрольная сумма на защите Linux/FreeBSD

Из всех аспектов деятельности системного администратора наиболее интересным и в то же время самым сложным является обеспечение безопасности существования системы. Эту тему на различных курсах обычно излагают довольно поверхностно, но защита, определенно, наиболее важная часть работы, вне зависимости от назначения компьютера и типа операционной системы, установленной на нем. После того как компьютер станет доступным тысячам пользователей в Интернете или даже десятку сотрудников в небольшом офисе, придется львиную долю времени уделять проблеме бесперебойной и стабильной работы сервера, недопущению утечки конфиденциальной информации. Причем уделять внимание данному вопросу необходимо не время от времени, а целенаправленно и постоянно. Иначе в один прекрасный день на главной странице сайта появится надпись, что ваш сайт взломан. И это, кстати, не самое страшное, что может произойти. По теории защиты написано много книг и много еще будет написано. Это очень сложная тема, и надеяться, что в одной статье будут даны ответы на все вопросы, тоже не стоит.

Начнем, пожалуй, с покупки дистрибутива. Лицензия Linux/FreeBSD хоть и позволяет использовать дистрибутив, купленный на радиорынке, так же, как и купленный официально, но доверять веб-сервер стоимостью свыше тысячи у.е. диску за несколько десятков рублей я бы не стал. Вполне вероятно, что это просто слитый с сайта ISO-образ, записанный на болванку, но точно гарантировать этого никто не может. Кто помешает заменить некоторые пакеты на доработанные под свои нужды с трояном внутри. Причем выдумывать самому ничего и не надо, все давно уже есть в паутине. Если все же другого выхода нет, или просто есть необходимость в установке программы, не входящей в основной дистрибутив, то всегда его нужно проверить на контрольную сумму. На большинстве ftp-архивов рядом с файлом можно найти информацию о контрольной сумме: либо в отдельном файле, например, CHECKSUM.MD5, либо непосредственно на веб-странице. Такая проверка по алгоритму MD5 хоть как-то гарантирует, что в файле никаких изменений не произведено, и перед вами действительно находится оригинал. Узнать контрольную сумму скачанного файла очень просто:

$ md5sum mysql-max-3.23.55-unknown-freebsd4.7-i386.tar.gz

99b543fbe12c2980c66d365ca68e819b

Теперь, сравнив обе контрольные суммы, можно сделать вывод. Проверка контрольной суммы должна войти в привычку при каждой установке программного обеспечения. По этой же причине никогда не стоит брать файл с первого попавшегося сервера, лучше всего зайти на домашнюю страницу или специальные сайты, предназначенные для этого: http://rpmfind.net, http://www.freshports.org. И еще один момент, связанный с установкой новой программы под FreeBSD. Если понадобилась программа, которой нет в дистрибутиве, или ее новая версия, тогда, несмотря на то что можно пойти сразу на сайт и скомпилировать ее из исходников, советую все же сначала обратиться к дереву пакаджей или портов. Включение в них утилиты свидетельствует о том, что программа прошла некоторое тестирование на совместимость и безопасность и не станет, по крайней мере, причиной краха системы. В данном случае проверка контрольной суммы происходит автоматически без вмешательства пользователя. К тому же это самый простой и безопасный способ установить новое ПО на вашу систему. Бывает, что компиляция с помощью порта, в том числе и по причине неправильной контрольной суммы, завершается с ошибкой. Здесь может помочь обновление дерева портов. В крайнем случае можно обратиться к человеку, поддерживающему данный порт (MAINTAINER), за консультацией и помощью. Узнать электронный адрес очень просто. Зайдите в каталог нужного порта и дайте команду:

$ more Makefile | grep MAINTAINER

MAINTAINER= anarcat@anarcat.dyndns.org

Отправьте по этому адресу вывод компилятора и информацию о системе (uname -a) и не забудьте заранее поблагодарить за помощь.

С помощью контрольной суммы можно не только проконтролировать устанавливаемые программы. Первое, что злоумышленник произведет в вашей системе, – это установит или, скорее всего, изменит некоторые программы. При этом, например, стандартная и довольно часто используемая программа ps может быть заменена на другую с трояном внутри, а команда ls может не заметить созданные злоумышленником каталоги. Чтобы избежать такого безобразия и иметь некоторый инструмент, позволяющий проконтролировать целостность системных файлов, применяются утилиты, которые автоматически проверяют значения контрольных сумм файлов и каталогов и заносят их в свою базу данных. Впоследствии системный администратор может в автоматическом режиме сверить оригинальную, созданную при установке, базу данных с имеющимися в системе файлами и при расхождении контрольных сумм выдать предупреждение по электронной почте. В таком случае можно сразу узнать о вторжении и оценить ущерб. При этом сразу хочется отметить, что данные средства отнюдь не отменяют, а, скорее, дополняют другие методы защиты. Причем средства, контролирующие состояние файлов, имеют некоторое преимущество перед программами, выявляющими вторжение по наличию определенных сигнатур, хотя ничто не мешает использовать комплексный подход.

Наиболее популярным средством для решения этой задачи является утилита Tripwire. Данная утилита доступна как OpenSource (http://www.tripwire.org) и как 30-дневная ознакомительная версия (http://www.tripwire.com). Скачать утилиту можно с сайта http://download.sourceforge.net/tripwire, по последнему адресу дополнительно можно найти документацию tripwire-docs.

Для FreeBSD проще установить OpenSource Tripwire, воспользовавшись системой портов.

# cd /usr/ports/security/tripwire

# make install clean

Единственный момент при установке, который может вызвать замешательство,– это когда программа спрашивает после просмотра лицензии:

Please type "accept" to indicate your acceptance of this license agreement. [do not accept]

Необходимо напечатать accept, нажатие Enter приведет к немедленному выходу из программы установки и ее придется повторить.

При компиляции в других системах первоначально необходимо раскомментировать строки в файле /src/Makefile для переменной SYSPRE в соответствии с используемой системой (Linux по умолчанию). Далее следует ввести:

# make all

или

# make *_r(d )

для установки одной выбранной программы и следовать дальнейшим указаниям программы. Установочные скрипты сами создадут ключи и инициируют базу данных. После установки при помощи rpm-пакетов следующим шагом необходимо произвести первоначальную инициализацию базы данных. Но для того чтобы не пришлось этого делать дважды, лучше всего сразу отредактировать файлы конфигурации и политик. Для этого в каталоге /etc/tripwire (/usr/local/etc/tripwire – FreeBSD) имеются два шаблона в виде текстовых файлов.

В файле twcfg.txt содержится системно-специфическая информация о размещении файлов базы данных, редактор, используемый по умолчанию, программа и ее параметры для отправки почты. А в файле twpol.txt – файл политики, состоящий из серии правил, что должен контролировать tripwire, данные для объектов контроля, серьезность контролируемого объекта и адрес электронной почты (emailto =) для каждой группы контроля, на который высылается уведомление о нарушении (если требуется указать сразу несколько адресов – все их можно перечислить через запятую). Здесь же желательно сменить TEMPDIRECTORY = /tmp на каталог с нормальными правами доступа (в /tmp для всех rwx).

Чтобы защитить против неправомерной модификации все важные Tripwire-файлы, они сохранены на диске в закодированной и подписанной форме. Сама база данных, политики, конфигурация и опции файла отчета защищены с El Gamal асимметричной криптографией с сигнатурой в 1024 бита. El Gamal использует набор ключей с одним открытым ключом и одним закрытым ключом шифрования. В криптографической системе Tripwire два файла ключей хранят public/private ключевую пару. Файлы конфигурации и политики защищаются от записи общим ключом, а сама база данных и отчеты – локальным ключом. Для чтения достаточно доступного публичного ключа, для записи требуется частный ключ, защищаемый парольной фразой. Поэтому после их редактирования, в соответствии с реальными настройками системы, необходимо запустить скрипт twinstall.sh, находящийся в этом же каталоге. Далее программа запросит site- и local-фразы (желательно не менее 8 символов) для генерации соответствующих ключевых пар. После этого в каталоге образуются зашифрованные файлы конфигурации и полиса tw.cfg и tw.pol, а также файлы ключей (/etc/tripwire/site.key и /etc/tripwire/host-local.key). В целях безопасности рекомендуется после окончания процедуры инсталляции удалить файлы шаблонов с данного каталога.

Далее инициируем базу данных.

#  /usr/sbin/tripwire--init

При этом после запроса локального пароля программа создает отпечаток важных системных файлов (размер, контрольная сумма, права, время доступа и т. д.), записывает ее в файл в каталоге /var/lib/tripwire/$(HOSTNAME).twd. Во время создания базы данных обратите внимание на сообщения об ошибках. Например:

### Filename: /bin/ash ### No such file or directory ### Continuing... ### Warning: File system error. ### Filename: /bin/ash.static ### No such file or directory ### Continuing...

Это означает, что в конфигурационном файле занесена излишняя информация. Желательно тут же подправить, иначе эти сообщения потом постоянно будут вас преследовать и дополнительно перегружать лог-файл.

Затем эта база данных ежедневно сравнивается с текущим состоянием файловой системы, позволяя обнаружить добавленные, измененные и удаленные файлы, с выдачей довольно подробных отчетов. Такое расположение файла удобно при запуске утилиты проверки согласованности файловой системы с помощью демона cron, позволяющей полностью автоматизировать данный процесс, включая информирование по указанному электронному адресу о результатах проверки. Но обнаружив присутствие утилиты при получении определенных прав, злоумышленник может заменить (обновить) базу данных или полностью переустановить tripwire (что гораздо проще), и после такой модификации утилита проверки не заметит подвоха. И вы будете получать по почте сообщения о том, что с системой все нормально, пока в один прекрасный день не обнаружите несовпадение парольных фраз. Такой вариант также предусмотрен разработчиками, для этого необходимо поместить отформатированную дискету в дисковод и присвоить значению переменной TRIPWIRE_FLOPPY= YES с командой make install:

# make install TRIPWIRE_FLOPPY= YES

чтобы создать резервную базу данных:

# make floppy

После этого на дискете окажется все, что необходимо для восстановления системы и автономной работы утилит: копия начальной базы данных системы и дополнительно утилиты tripwire, twcheck и gunzip и копия файла tw.config. Хотя есть вероятность, что все это не поместится в 1.44 Мб флоппи-диска даже после архивирования, единственным выходом будет уменьшить количество объектов базы данных. В любом случае желательно резервировать всю систему на всякий случай и Tripwire в том числе, и периодически сверять оригинальную и рабочую базы данных.

Проверить систему можно запустив программу tripwire без аргументов (или tripwire --check, кому как нравится), при этом программа сравнивает текущее состояние системы с сохраненным в базе данных и при несоответствии выдает сообщение, при этом отмечается даже такая мелочь, как изменение времени модификации программы. Аналогично производит ежедневную проверку демон cron посредством /etc/cron.daily/tripwire-check. А чтобы не ждать, пока система все проверит, можно указать опцию --email-report:

# tripwire --check --email-report

и сообщение электронной почты будет послано всем получателям, указанным в файле политики, используя формат сообщения, определенное в EMAILREPORTLEVEL. Но перед началом эксплуатации желательно проверить работу электронной почты с помощью команды:

# tripwire --test --email user@domain.com

Если нет необходимости в проверке всей системы, то можно сразу указать, какие объекты необходимо проверить.

# tripwire --check object1 object2 object3

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

# tripwire --check --severity 66

Или используя поверку правил по имени rulename, которые прописаны в файле tw.pol. Например, для проверки системных файлов:

# tripwire --check --rulename "File System and Disk Administraton Programs"

Конечно же, при необходимости частого использования данного типа проверки желательно длинные имена, используемые в файле по умолчанию, заменить на свои, покороче. Ключ --interactive позволяет изменить БД в диалоговом режиме. Запускается текстовый редактор при помощи --visual имя-редактора или прописанный в переменной EDITOR в конфигурационном файле (или переменные окружения VISUAL или EDITOR) и предоставляется возможность отредактировать форму изменения БД, в которой каждый заносимый файл надо отметить крестиком в секции Object Summary, при этом запрашивается парольная фраза.

Конечно же, со временем некоторые утилиты обновляются или удаляются и заменяются другими, поэтому с помощью опции --update можно обновить базу данных:

# tripwire --update

Для обновления всей системы:

# tripwire --update /usr/sbin/sshd

А если указать конкректную программу, то обновляются сведения только о ней.

Программа после проверок создает отчет, по умолчанию это файл /var/db/tripwire/report/(HOSTNAME)-$(DATE).twr. Файл после создания будет иметь примерно такое название: localhost-20030327-071039.twr

Но при помощи команды:

# tripwire --check --twrfile /var/lib/report/myreport.twr

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

По умолчанию при генерации отчетов используется REPORTLEVEL=3 (Concise Report), отражающий довольно подробную информацию с выводом ожидаемых и наблюдаемых значений и прочее, который можно изменить в файле tw.cfg. Tripwire позволяет гибко задавать отчеты, в зависимости от необходимости в той или иной информации, для этого на ходу изменяется report_level в пределах от 0 до 4.

# twprint --print-report --report-level 1 --twrfile /var/lib/report/report.twr

При необходимости внесения глобальных изменений всегда можно будет получить расшифрованную копию конфигурационного файла при помощи команды:

# twadmin –print-cfgfile >  /etc/tripwire/twcfg.txt

После внесения необходимых изменений и сохранения зашифрованный файл создается командой:

# twadmin --create-cfgfile --site-keyfile /etc/tripwire/site.key /etc/tripwire/twcfg.txt

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

Создаем копию файла политик:

# twadmin --print-polfile > /etc/tripwire/twpol.txt

И после внесения необходимых изменений модифицируем политики:

# tripwire --update-policy /etc/tripwire/twpol.txt

Ключевые site- и local-файлы образуются во время первого запуска, но иногда возникает необходимость в их полной замене. Парольная фраза меняется только одновременно со сменой ключей, поэтому чтобы сменить парольную фразу, надо предварительно дешифровать все файлы, сгенерировать новые ключи, затем уже зашифровать файлы с новыми ключевыми данными. При этом, если забудете парольную фразу или удалите файлы с ключами, то зашифрованные файлы, т.е. конфигурация, политики, база данных и отчеты при их шифровании будут недоступны. В этом случае лучшим решением будет переустановка всей системы. И кстати, шифровка также не помешает хакеру при наличии определенных прав просто удалить любой файл, включая саму базу данных tripwire, поэтому использование tripwire не отменяет обязательности резервного копирования.

Узнать, какой ключ был использован (и был ли вообще) для шифровки файла можно при помощи:

# twadmin --examine file1 file2

Убрать шифровку ( при этом запрашивается парольная фраза, сам файл остается в двоичном формате):

#  twadmin --remove-encryption file1 file2

Затем создание нового ключа:

# twadmin --generate-keys --local-keyfile /etc/tripwire/localkey.key

или

# twadmin --generate-keys --site-keyfile /etc/tripwire/sitekey.key

И шифрование файла:

# twadmin --encrypt --local-keyfile /etc/tripwire/localkey.keyfile1 file2

или

# twadmin --encrypt --site-keyfile /etc/tripwire/sitekey.key file1 file2

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

# twprint --print-dbfile > db.txt

Или для произвольной базы данных:

# twprint --print-dbfile --dbfile otherfile.twd > db.txt

Аналогично для файла с отчетом:

# twprint --print-report --twrfile имя-файла-с-отчетом

В комплекте пакета имеется вспомогательная программа, вычисляющая контрольную сумму методами CRC-32, MD5, HAVAL и SHA в реализации tripwire, что позволяет сравнить производительность различных методов:

# /usr/sbin/siggen /var/lib/tripwire/localhost.twd

---------------------------------------------------------- Signatures for file: /var/lib/tripwire/localhost.twd CRC32      BVr6P8 MD5            CyDxlDF7Mnuz3njdkViXBB SHA            OQlEAmFhfbcDp8ExomcqkJ8HGNS HAVAL      BIR2NV6sOozXF9X92hqkyA ----------------------------------------------------------

Конечно, нельзя говорить, что использование Tripwire является панацеей от всех бед, но использование данной утилиты может существенно усложнить жизнь тем, кому хочется покопаться в чужом компьютере и подать предупреждающий знак системному администратору, когда такой момент наступит. В следующий раз рассмотрим еще некоторые утилиты, позволяющие повысить защищенность системы.

Формат конфигурационного файла настроек /etc/tripwire/tw.cfg (twcfg.txt)

Содержит пути к вспомогательным программам, адрес электронной почты, каталоги для размещения конфигурационных файлов Tripwire. Файл структурирован как список пар имя_переменной = значение. Любая строка, начинающаяся с #, считается комментарием. При этом в файле могут быть определены переменные, к которым можно обращаться как $(имя_переменной). Две переменные предопределены и не могут быть изменены:

• HOSTNAME – простое имя хоста;
• DATE – представление времени в формате 20030427-111033.

Обязательные переменные:

• POLFILE = /etc/tripwire/tw.pol (имя файла политик);
• DBFILE = /var/lib/tripwire/$(HOSTNAME).twd (имя файла с базой данных);
• REPORTFILE = /var/lib/tripwire/report/$(HOSTNAME)-$(DATE).twr (шаблон имен файлов с отчетами);
• SITEKEYFILE = /etc/tripwire/site.key (общий ключ);
• LOCALKEYFILE = /etc/tripwire/$(HOSTNAME)-local.key (локальный ключ).

Опциональные переменные:

• EDITOR = /bin/vi (имя текстового редактора, используемого в интерактивном режиме; если он неопределен, будет использована программа, прописанная в системной переменной $VISUAL или $EDITOR);
• TEMPDIRECTORY = /tmp (каталог для хранения временных файлов);
• LATEPROMPTING = false (откладывать запрос парольной фразы до последнего, чтобы пароль меньше находился в системной памяти);
• SYSLOGREPORTING = true (выдавать на syslog уровни «user» и «notice» – сообщения о создании базы данных, проверках, изменениях базы данных и политики, с уровенем подробности – 0);
• LOOSEDIRECTORYCHECKING = false (при установке в true не выдает излишние сообщения о изменениях atime и mtime для каталогов, в которых был добавлен или удален контролируемый файл; эквивалентно добавлению -snacmblCMSH для всех каталогов);
• REPORTLEVEL = 3 (уровень подробности отчета по умолчанию для twprint). Переменные для настройки уведомления по e-mail;
• GLOBALEMAIL = (добавить этот список адресов к получателям отчетов по почте);
• MAILMETHOD = SMTP или SENDMAIL – протокол для передачи почтовых сообщений, используемый tripwire;
• SMTPHOST = (имя домена или IP-адрес сервера SMTP; игнорируется, если предыдущая переменная не установлена в SMTP);
• SMTPPORT = 25 (определяет номер порта, используемый с SMTP, игнорируемым, если MAILMETHOD не SMTP);
• MAILPROGRAM = /usr/sbin/sendmail -oi -t (Определяет полный путь к программе, используемой для электронной почты, если MAILMETHOD, если MAILMETHOD установлен в SENDMAIL, это может быть любая подобная программа, удовлетворяющая RFC 822);
• EMAILREPORTLEVEL = 3 (уровень подробности отчета для почтовых извещений);
• MAILNOVIOLATIONS = false (не посылает письма при отсутствии нарушений политик, при установке в true и отсутствии каких-либо нарушений будут приходить сообщения об этом, что рекомендуется для контроля функционирования системы, но увеличивает количество писем).

Формат конфигурационного файла политик /etc/tripwire/tw.pol (twpol.txt)

Файл политик состоит из серии правил, определяющих то, какой реквизит для каждого объекта должен быть собран и сохранен в файле базы данных. Каждый объект в файле политик связан с маской свойства, которая описывает то, что Tripwire должен контролировать, и которые могут безопасно игнорироваться. Настраивая различные аспекты файла политик, администратор системы может через Tripwire управлять проверкой целостности системы.

Основным компонентом файла являются правила (rules), в которых определяются проверяемые свойства для каждого объекта. При этом файлы и в каталогах наследуют правила родительского каталога, но при условии, что внутренние каталоги находятся на одном и том же дисковом устройстве, иначе для всех «выпавших» правила нужно определить отдельно. Как и в конфигурационном файле, возможно использование комментариев и переменных. Кроме проверяемых объектов, могут дополнительно указываться игнорируемые, что позволяет исключить «лишние» файлы.

object name -> property_mask [attribute=value …];

! object name;

При задании имени объекта необходимо помнить, что пробелы в имени игнорируются, поэтому их требуется заключить в кавычки. То же касается как самой кавычки, так и всех специальных символов применительно к С++ (!{}>(),;=$#|+’ и , ,v, , , f, a, , ?, ’, "), которые можно экранировать обратной чертой, а также чисел, заданных в восьмеричной или шеснадцатеричной форме.

Например:

"/tex73t2"

Свойства, которые будут проверяться, задаются маской свойств, при этом каждому соответствует своя буква. При отсутствии свойств объект не проверяется. Если перед свойством стоит минус «-», то данное свойство игнорируется, если плюс «+», то включается проверка данного свойства. Если знака перед буквой нет, то подразумевается предыдущий в данном правиле знак или знак плюс при отсутствии знаков. Проверяются следующие свойства ([+-]*[pinugtsldbamcrCMSH])+:

• p – права доступа;
• i – inode;
• n – число жестких ссылок;
• u – uid;
• g – gid;
• t – тип файла;
• s – размер;
• l – ожидается, что файл будет расти; если он уменьшился, то фиксируется нарушение (полезно, например, для журналов);
• d – номер устройства диска, на котором хранится соответствующий inode;
• b – число блоков;
• a – время доступа (несовместим с +CMSH, т.к. для вычисления суммы необходимо прочитать файл; доступ к содержимому директории меняет время доступа к ней. Можно избежать recurse = false, LOOSEDIREC-TORYCHECKING = true и правило -a);
• m – время модификации;
• c – время создания/модификации inode;
• r – для файлов устройств номер устройства;
• C – контрольная сумма по CRC-32, POSIX 1003.2 (самый быстрый, но наименее защищенный вариант из представленных);
• M – контрольная сумма по MD5 RSA Data Security;
• S – контрольная сумма по SHS/SHA-алгоритму;
• H – контрольная сумма по HAVAL.

Имеет смысл использовать CMSH для файлов парами, а не все четыре сразу, так как определение всех существенно замедлит производительность.

Атрибуты правил предназначены для того, чтобы изменить их поведение или обеспечить дополнительную информацию. При этом атрибуты записываются в виде списка имя = значение через запятую и могут применяться к отдельному правилу или группе правил.

/usr/lib -> $(ReadOnly) ( emailto = admin@foo.com ) ;

Группа правил заключается в фигурные скобки. Список атрибутов для группы правил записывается в скобках перед ней.

(attribute = value)

{

rule1;

rule2;

...

}

Индивидуальные атрибуты имеют больший приоритет, чем групповые, за исключением атрибута emailto – в этом случае атрибут добавляется. Пример.

(emailto = admin1@foo.com, severity = 90)

{

/etc/dog-> +pingus (severity = 75);

/etc/cat-> $(Dynamic) (emailto = admin2@foo.com);

}

Могут использоваться следующие атрибуты:

• rulename – по умолчанию, простое имя файла; используется в отчетах, для группировки правил, для проверки только части правил, желательно для удобства использовать короткое, но понятное значение;
• emailto – адрес электронной почты, на который по умолчанию высылаются сообщения; чтобы указать несколько адресов, надо перечислить их через точку с запятой и заключить в кавычки;
• severity – определяет уровень серьезности правила (от 0 до 1000000, по умолчанию – 0;) чем больше, тем серьезнее; проверку можно запускать только для правил указанного уровня или выше; в командной строке могут использоваться ключи:
• high – уровень 100;
• medium – уровень 66;
• low – уровень 33.
• recurse – рекурсивная проверка директорий, true (-1) по умолчанию, т.е. полный просмотр, false (0) или натуральное число (максимальный уровень вложенности до 1000000).

Tripwire поддерживает маленький набор preprocessor-подобных директив, которые группируют правила, обеспечивают условное выполнение и восполняют некоторую диагностику и действия отладки. Первичное намерение этого механизма состоит в том, чтобы поддержать разделение файла политики среди нескольких машин. Директивы имеют следующий синтаксис:

@@directive [arguments]

При этом сама директива не может быть получена как значение переменной, но переменные могут использоваться в качестве параметров. Обрабатываются следующие директивы:

• @@section имя – предназначен в основном для работы с Windows NT, но для Unix обрабатываются только правила в первой секции с именем FS; если секций нет, то обрабатываются все правила, которые будут интерпретироваться как правила UNIX, что может создавать проблему, если файл политики, разработанный для систем Windows NT используется с UNIX; в секции GLOBAL определяются глобальные переменные;
• @@ifhost имя-хоста { || имя-хоста } – использовать правила только для указанного хоста (хостов); условия могут быть вложенными;
• @@else и @@endif – обработка условных выражений вместе с @@ifhost:

@@ifhost machine1 || machine2

/usr/bin -> +pinug ;

@@else

/usr/bin -> +pinugsmC ;

@@endif

• @@print строка в кавычках – вывод на stdout;
• @@error строка в кавычках – вывод на stdout и завершение со статусом 1;
• @@end – любой дальнейший текст в файле игнорируется; не может использоваться внутри группы или условного блока.

Для удобства можно определять и использовать в файле политики два типа переменных.

Глобальные переменные имеют видимость всюду в файле политики, в то время как локальные переменные, определенные в разделе UNIX файлы политики имеют видимость только в пределах того раздела.

В случае же, где глобальная и локальная переменные имеют то же самое название, локальная переменная будет иметь приоритет в ее разделе, временно маскируя глобальную переменную. Значение переменной присваивается командой имя_переменной = значение, подстановка значения осуществляется конструкцией $(variable). Первоначально имеются следующие предопределенные переменные:

• ReadOnly = +pinugsmtdbCM-raclSH (предполагается, что содержимое файлов не будет изменяться, только чтение);
• Dynamic = +pinugtd-rsacmblCMHS (предполагается частое изменение содержимого файлов, например, /home, /var);
• Growing = +pinugtdl-rsacmbCMSH (предполагается, что файлы будут только расти, например, журналы);
• IgnoreAll = -pinusgamctdrblCMSH (проверяется только лишь наличие или отсутствие файла, остальное игнорируется);
• IgnoreNone = +pinusgamctdrbCMSH-l (включает все имеющиеся свойства и предназначен для дальнейшего конструирования собственной маски: $(IGnoreNone)-ar, например, для предупреждения нарушения времени доступа);
• Device = +pugsdr-intlbamcCMSH (для устройств и файлов, которые нельзя открывать).

Приложение

Уровни отчетов

Уровень 0

Отчет одной строкой. Появляется всегда в строке Subject отчета, высылаемого по e-mail.

TWReport имя-хоста дата-и-время V:число-нарушений S:макс-уровень A:добавлено R:удалено C:изменено

TWReport LIGHTHOUSE 19991021134026 V:45 S:100 A:2 R:1 C:6

Уровень 1

Список имен измененных файлов в виде, легко разбираемом программой автоматического восстановления или подобной. Каждая строка состоит из ключевого слова (Added, Modified), двоеточия и имени файла.

Added: /usr/bin/bash Modified: /usr/bin

Уровень 2

Суммарный отчет, включает список нарушений с указанием имен правил, список добавленных, измененных и удаленных файлов. Секция Object Summary содержит подробный список файлов, которых затронули изменения.

Уровень 3

Суммарный отчет, включает список нарушений с указанием имен правил, список добавленных и удаленных файлов, ожидаемые и реальные свойства измененных файлов. Также выводит дополнительные подробности.

Уровень 4

Суммарный отчет, выводящий максимальное количество деталей, список нарушений с указанием имен правил, список добавленных, измененных и удаленных файлов, детальный отчет по каждому добавленному файлу (все свойства), каждому измененному файлу (все проверяемые, ожидаемые и реальные свойства), каждому удаленному файлу (все проверяемые и ожидаемые свойства). При этом отличающиеся параметры помечаются звездочкой в начале строки.