netbsd-fsread: filename eq “/etc/ld.so.conf” then permit

    netbsd-__fstat13: permit

    netbsd-close: permit

    netbsd-munmap: permit

    netbsd-fsread: filename eq “/lib/libc.so.12.114.1” then permit

    netbsd-__sysctl: permit

    netbsd-fsread: filename eq “/etc/mallic.conf” then permit

    netbsd-break: permit

    netbsd-ioctl: permit

    netbsd-write: permit

    netbsd-fswrite: filename eq “/home/01mer/labs/systr/test” then permit

    netbsd-exit: permit

Синтаксис правил достаточно прост:

[системный вызов] [условие] [действие]

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

Рассмотрим полученные правила.

Policy: /home/01mer/labs/systr/proga, Emulation: netbsd

Указывается, для какого бинарного файла политика описана ниже. Полный путь к исполняемому файлу нужен для того, чтобы исключить возможность применения политики для файла с таким же именем, но располагающимся в другом месте. Emulation: netbsd показывает, что будет использоваться ABI ОС NetBSD.

    netbsd-mmap: permit

Как видно из названия, системному вызову mmap разрешено исполняться. Для позволения выполнения системного вызова используется действие – permit, для запрещения deny.

    netbsd-fsread: filename eq “/etc/ld.so.conf” then permit

Тут мы видим, что системному вызову fsread будет разрешено выполниться в том случае, если запрошенный им файл будет /etc/ld.so.conf. Стоп, скажет внимательный читатель, системного вызова fsread не существует! И будет абсолютно прав. По умолчанию в systrace применяется использование псевдонимов для системных вызовов. Например: fsread является псевдонимом для stat, lstat, readlink, access, open. Но при желании режим использования псевдонимов можно отключить. В дальнейшем комментировании всего файла конфигурации смысла не вижу – все должно быть понятно и без этого.