Я профилирую некоторое фирменное программное обеспечение, чтобы создать набор требований к разрешениям и политик 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
Кто-нибудь знает, как это сделать? Я пока не могу найти ответ.
решение1
Вопреки обычной практике, перевод SELinux в permissiveрежим и регистрация всех отказов AVC с целью разработки модуля политики может привести к включению в такую политику неправильного набора разрешений.
Примером этого может быть следующее: предположим, что для нормальной работы этого фирменного программного обеспечения требуетсядоменный переходв разрешающем режиме переход не происходит, и создается впечатление, что исходный домен требует все разрешения, записанные как отказы AVC (SELinux Cookbook Свена Вермейленасодержит несколько ссылок на эту потенциальную проблему).
Лучшим подходом к созданию модуля политики для фирменного программного обеспечения было бы изначально поддерживать SELinux в принудительном режиме, чтобы гарантироватьнаименьшая привилегиявозможное предоставляется.
Далее следует изучить программное обеспечение как в сети (есть ли у него документация?), так и офлайн ( ss, strace, ipcs, ...), чтобы подробно определить его архитектурный дизайн, а именно, но не ограничиваясь:
файлы, которые также следует разделить на подгруппы (конфигурация, транзакции, журналы, ...)
процессы, службы (есть ли у программного обеспечения скрипт systemd/upstart/init?)
сетевое подключение (входящий и исходящий трафик, порты, ...)
пользователи, группы
Имея под рукой всю эту информацию, вы сможете приступить к разработке политики для этого программного обеспечения.
Вам необходимо:
создать файл filecontexts, определяющий контекст безопасности всех задействованных файлов
создайте файл интерфейсов, определяющий ваш домен с точки зрения всех взаимодействий между файлами, процессами, портами, пользователями, переходами между доменами, ...
создать файл принудительного применения типа, описывающий, каким пользователям предоставляется доступ к указанному выше домену, а также фактические правила
Скомпилируйте и загрузите его, проверьте отказы AVC, отладьте и улучшите свою политику. Промойте и повторите.
Последняя цитата из упомянутой выше книги:
Некоторые разработчики политик любят запускать разрешающий режим приложения (либо запуская всю систему в разрешающем режиме, либо отмечая этот конкретный домен как разрешающий домен), регистрируя все выполненные доступы (через отказы AVC) и улучшая политику на основе этой информации. Хотя это может дать более быструю рабочую политику, эти разработчики также рискуют тем, что они добавят слишком много привилегий в политику, что очень трудно оспорить и изменить позже. Вместо этого мы позволяем SELinux предотвращать доступы и смотрим, как реагирует приложение. Основываясь на регистрации ошибок приложения или поведении приложения и отказе(ях) AVC, видимых в журналах, мы можем получить хорошую картину того, какие привилегии действительно необходимы.