Я профилирую какое-то проприетарное программное обеспечение, чтобы создать набор требований к разрешениям и политик SELinux, которые позволят ему установить и запустить в Oracle Linux (или любой производной от RHEL).
Я запускаю SELinux в разрешающем режиме, я запустил semodule -DB, чтобы отключить «dontaudit», и я просматриваю /var/log/audit/audit.log, чтобы увидеть результаты.
Однако я также хотел бы видеть ВСЕ, что разрешено (не только отрицания или аудитлоу), которых, судя по этому, кажется большинство:
[root@aw-selinuxtest ~]# seinfo --stats
Statistics for policy file: /etc/selinux/targeted/policy/policy.24
Policy Version & Type: v.24 (binary, mls)
Classes: 81 Permissions: 237
Sensitivities: 1 Categories: 1024
Types: 3852 Attributes: 291
Users: 9 Roles: 12
Booleans: 228 Cond. Expr.: 268
Allow: 311381 Neverallow: 0
Auditallow: 133 Dontaudit: 0
Type_trans: 38576 Type_change: 38
Type_member: 48 Role allow: 19
Role_trans: 368 Range_trans: 5601
Constraints: 90 Validatetrans: 0
Initial SIDs: 27 Fs_use: 24
Genfscon: 84 Portcon: 471
Netifcon: 0 Nodecon: 0
Permissives: 91 Polcap: 2
Кто-нибудь знает как это сделать? Я пока не могу найти ответ.
В отличие от обычной практики, установка SELinux на permissive режим и запись всех отказов AVC для разработки модуля политики может привести к тому, что в такую политику будет включен неправильный набор разрешений.
Примером этого может быть следующее: предположим, что для нормальной работы этой проприетарной программы требуется переход домена, в разрешающем режиме переход не происходит, и похоже, что исходный домен требует всех разрешений, записанных как отказы AVC (Поваренная книга SELinux Свена Вермёлена содержит несколько ссылок на эту потенциальную проблему).
Лучшим подходом к созданию модуля политики для проприетарного программного обеспечения было бы в первую очередь поддерживать SELinux в принудительном режиме, чтобы гарантировать наименьшая привилегия возможно предоставляется.
Далее следовало бы изучить программное обеспечение как в Интернете (есть ли у него документация?), Так и в автономном режиме (ss, strace, ipcs, ...) для детального определения его архитектурного решения, а именно, но не ограничиваясь:
файлы, которые также следует разделить на подгруппы (конфигурация, транзакции, журналы, ...)
процессы, службы (есть ли в программе сценарий systemd / upstart / init?)
подключение к сети (входящий и исходящий трафик, порты, ...)
пользователи, группы
Имея всю эту информацию под рукой, вы сможете начать разработку политики для этого программного обеспечения.
Вам потребуется:
создать файл контекстов файла, определяющий контекст безопасности всех задействованных файлов
создайте файл интерфейсов, определяющий ваш домен с точки зрения всех взаимодействий между файлами, процессами, портами, пользователями, переходами между доменами, ...
создать файл принудительного применения типа, описывающий, каким пользователям предоставлен доступ к указанному выше домену, и фактические правила
Скомпилируйте и загрузите, проверьте отказы AVC, отладьте и улучшите свою политику. Промыть и повторить.
Последняя цитата из упомянутой выше книги:
Некоторым разработчикам политик нравится запускать разрешающий режим приложений (либо запускать всю систему в разрешающем режиме, либо отмечать этот конкретный домен как разрешающий домен), регистрировать все выполненные доступы (через отказы AVC) и улучшать политику на основе этой информации. Хотя это может обеспечить более быструю работу политики, эти разработчики также рискуют добавить к политике слишком много привилегий, что очень сложно оспорить и изменить позже. Вместо этого мы позволяем SELinux предотвращать доступ и смотрим, как реагирует приложение. Основываясь на регистрации ошибок приложения или поведения приложения, а также на отклонениях AVC, обнаруженных в журналах, мы можем получить хорошее представление о том, какие привилегии действительно необходимы.