Антихакинг в сети

Политика для named содержит 73 строки правил. В общем виде они выглядят так:
native-accept: permit
Когда /usr/sbin/named пытается использовать системный вызов acceptO для принятия соединения через сокет под «родным» ABI, это разрешается (permit). Остальные правила значительно более строгие. Вот пример для bind О — системного вызова, позволяющего программе запросить подключение к ТСР/1Р-порту:
native-bind: sockaddr match "inet-*:53" then permit
sockaddr — это имя аргумента, получаемого системным вызовом acceptO. Ключевое слово match указывает systrace на необходимость сравнения данной переменной со строкой inet-*:53 (в соответствии со стандартными правилами сравнения шаблонов). Таким образом, если переменная sockaddr соответствует строке inet-*:53, то соединение принимается. Эта программа может привязываться  к 53-му порту как по протоколу TCP, так и по UDP. Если атакующий осуществил взлом с использованием mate named, подключившись к порту с высоким номером, данная политика systrace сделает этот взлом нерабочим.
На первый взгляд это выглядит неверным:
native-chdir: filename eq "/" then permit native-chdir: filename eq "/namedb" then permit
Ключевое слово eq сравнивает одну строку с другой и требует точного совпадения. Если программа пытается перейти в корневой каталог или каталог /namedb, то systrace препятствовать этому не будет. Зачем разрешать доступ named к корневому каталогу? Вот зачем:
native-chroot: filename eq "/var/named" then permit
Системный вызов native chrootO можно использовать для того, чтобы назначить корневым каталог /var/named, и никакой иной. В данный момент каталог /namedb на самом деле является каталогом /var/named/namedb.