Понимаете ли вы принципы работы SELinux

Что проверяют

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

Как отвечать

Основа такая: обычные права решают, что можно пользователю, SELinux решает, что можно процессу, отдельным слоем поверх. Даже процесс от суперпользователя ограничен политикой. Механизм живёт в системах семейства RHEL, в Debian и Ubuntu ту же роль играет AppArmor.

Ключевые понятия:

• контекст безопасности на каждом файле, процессе и порте: пользователь, роль, тип, уровень. Смотрится через ls -Z, ps -Z, id -Z;
• type enforcement: главный механизм. Политика описывает, какому типу процесса что разрешено делать с каким типом объекта. Роли и уровни (RBAC и MLS) идут сверху и в типовой политике почти не трогаются;
• режимы: enforcing блокирует и пишет в журнал, permissive только пишет, disabled выключает совсем. Временно режим меняется командой, постоянно правкой конфига, а возврат из disabled требует переразметки файловой системы;
• переключатели политики: getsebool -a и setsebool -P, готовые тумблеры вроде разрешения веб-серверу ходить по сети.

Дальше разбор отказа: найти запись AVC в журнале аудита, объяснить её через audit2why, поправить разметку через semanage fcontext и restorecon, для нестандартного порта завести правило через semanage port.

Где спотыкаются

Лечат отказ выключением защиты. Ответ «ставлю permissive и работает» интервьюер засчитывает как отсутствие опыта: снимается весь слой, а не одно мешающее правило, хотя нужное почти всегда есть готовым переключателем.

Второе: правят контекст через chcon и удивляются, что после общей переразметки всё вернулось назад. Эта команда меняет метку только здесь и сейчас. Постоянное правило заводится в базе контекстов, а метки на диске приводятся к нему отдельной командой.

Третье: считают, что пустой журнал означает непричастность SELinux. Часть отказов скрыта правилами dontaudit, и пока полный аудит не включён, их не видно. Рядом ещё ловушка: контейнер получает свой контекст, и отказ виден на хосте, а не внутри.