我正在分析一些专有软件,以构建一组权限要求和 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 拒绝的所有权限(Sven Vermeulen 的 SELinux 手册包含对这一潜在问题的多处引用)。
为专有软件创建策略模块的更好方法是首先将 SELinux 保持在强制模式,以确保最小特权可能正在被授予。
接下来将研究该软件,包括在线(它有文档吗?)和离线(,,,ss
... )以详细确定其架构设计,即但不限于:strace
ipcs
文件,也应该分为子组(配置,交易,日志......)
进程、服务(该软件是否有 systemd/upstart/init 脚本?)
网络连接(入站和出站流量、端口……)
用户、群组
有了所有这些信息,您就可以开始为该软件制定策略。
您需要:
创建一个文件上下文文件,定义所有涉及文件的安全上下文
创建一个接口文件,根据文件、进程、端口、用户、域转换等之间的所有交互来定义您的域……
创建一个类型执行文件,描述哪些用户被授予访问上述域的权限以及实际规则
编译并加载它,检查 AVC 拒绝,调试并增强您的策略。冲洗并重复。
最后引用上述书中的一句话:
一些策略开发人员喜欢运行应用程序宽容模式(通过在宽容模式下运行整个系统或将此特定域标记为宽容域),注册所有执行的访问(通过 AVC 拒绝)并根据该信息增强策略。虽然这可能会提供更快的工作策略,但这些开发人员也会面临向策略添加过多权限的风险,而这在以后很难提出质疑和更改。相反,我们让 SELinux 阻止访问并查看应用程序如何反应。根据应用程序的错误日志记录或应用程序的行为以及通过日志看到的 AVC 拒绝,我们可以很好地了解真正需要哪些权限。