# su

# make relabel

Для файлов, созданных уже после установки системы, такой пользователь будет назначаться, исходя из реального идентификатора пользователя в системе (точнее, процесса, создающего файл). Так как понятие роли неприменимо к файлам, а только к пользователям (процессам), то все файлы имеют одинаковую метку-роль object_r. И файлы с различными требованиями защиты имеют различные типы, например, /boot – boot_t, а /etc имеет тип etc_t . При включении во время компиляции ядра опции SELinux Development Support система поначалу начинает функционировать в разрешающем режиме (permissive). Другими словами, вместо блокировки неразрешенных политикой защиты функций, все такие незаконные действия будут просто регистрироваться в /var/log/messages, после чего они будут разрешены. Этот режим удобно использовать для выяснения политик доступа специфичной для конкретной системы и подправить конфигурацию. Для того чтобы включить затем режим принуждения (enforcing), необходимо включить его командой avc_toggle, тогда незаконные функции будут полностью блокированы. Но самым непривычным для сисадмина будет то, что введя команду на выполнение, иногда получаем такой вот ответ от системы. Проверяем, кто мы:

[root@grinder /]# id

uid=0(root) gid=0(root) groups=0(root) context=root:user_r:user_t sid=260

Обратите внимание на роль user_r. Проверяем режим защиты:

[root@grinder /]# avc_toggle

enforcing

А теперь пробуем изменить его в разрешающий режим.

[root@grinder /]# avc_toggle

avc_toggle: Permission denied

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

[root@grinder /]# newrole -r sysadm_r