/dev/log                        h

        -CAP_ALL

       +CAP_NET_ADMIN

        bind    disabled

        connect disabled

}

Активировал GRSecurity, ошибок нет. Однако ночью сервер повис. В логах было чисто, поэтому определить причину не представлялось возможным, однако было понятно, что все дело в GRSecurity. Самое интересное, что днем он работал нормально, а зависал исключительно ночью. Причем зависал настолько быстро, что система не успевала ничего записать в лог. И только на третий или четвертый день в логе отразилась попытка NeTAMS выполнить CAP_DAC_OVERRIDE. После добавления строки +CAP_DAC_OVERRIDE в ACL для NeTAMS зависания прекратились.

Кроме полного обучения системы доступно также обучение отдельных ролей или субъектов. Например, веб-сервер работает из-под пользователя apache. Для обучения системы добавляем в /etc/grsec/acl следующие строки:

role apache ul

Запускаем GRSecurity в режиме обучения (не полного!):

# gradm –E –L /var/log/grsec

Через некоторое время отключаем:

# gradm –D

формируем ACL:

# gradm –L /var/log/grsec –O /etc/grsec/acl

Затем редактируем получившуюся роль, убирая добавленные gradm комментарии и букву l из описания роли.

По такому же принципу происходит и обучение субъекта. Добавляем в нужную роль описание нужного субъекта, для которого необходимо получить ACL, например /bin/su:

subject /bin/su lo {

    /      h

    -CAP_ALL

      connect disabled

      bind disabled

}

и аналогично запускаем режим обучения. Здесь есть один тонкий момент – в процессе обучения GRSecurity не исправляет допущенные человеком ошибки, поэтому запускать режим обучения для роли или субъекта, в которые уже что-то добавлено, не имеет смысла. Поэтому прежде чем запустить режим обучения, рекомендуется полностью очистить субъект или роль.

После того как ошибки исчезнут совсем, для выполнения административных задач создадим специальную роль, которой будет разрешено все. Дописываем в /etc/grsec/acl:

role sysadmin sA

subject / {

    /      rwcdmxi

    +CAP_ALL

}

Чтобы специальная роль стала доступной, надо в той роли, откуда она будет вызываться, разрешить этот вызов. Допустим, заходим на сервер по ssh и через su получаем права пользователя root. Таким образом, за все действия теперь отвечает роль root. И чтобы в этом случае можно было перейти в роль sysadmin, надо в /etc/grsec/acl в описание роли root дописать следующую строку: