我正在分析一些专有软件以构建一组权限要求和 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
Run Code Online (Sandbox Code Playgroud)
有谁知道如何做到这一点?到目前为止,我正在努力寻找答案。
与通常的做法相反,将 SELinux 设置为permissive
模式并记录所有 AVC 拒绝以开发策略模块可能会导致此类策略中包含错误的权限集。
一个例子如下:假设这个专有软件的正常操作需要域转换,在许可模式下,转换不会发生,看起来源域需要记录为 AVC 拒绝的所有权限(Sven Vermeulen 的 SELinux Cookbook包含对这个潜在问题的几个参考)。
为专有软件创建策略模块的更好方法是首先将 SELinux 维持在强制模式,以确保授予尽可能少的特权。
下一步将是在网上进行查询软件,无论是(它有文件?)和线下(ss
,strace
,ipcs
,...)来具体确定其建筑设计,即,包括但不限于:
文件,这些文件也应该分成子组(配置、事务、日志……)
进程、服务(该软件是否有 systemd/upstart/init 脚本?)
网络连接(入站和出站流量、端口等)
用户、组
有了所有这些信息,您就可以开始为该软件制定策略。
您将需要:
创建一个文件上下文文件,定义所有涉及的文件的安全上下文
创建一个接口文件,根据文件、进程、端口、用户、域转换等之间的所有交互定义域。
创建一个类型强制文件,描述哪些用户被授予访问上述域的权限和实际规则
编译并加载它,检查 AVC 拒绝,调试和增强您的策略。冲洗并重复。
从上面提到的书中,最后引用一句:
一些策略开发人员喜欢运行应用程序许可模式(通过在许可模式下运行整个系统或将此特定域标记为许可域),注册所有执行的访问(通过 AVC 拒绝)并基于该信息增强策略。尽管这可能会提供更快的工作策略,但这些开发人员也将面临向策略添加太多特权的风险,而这在以后很难挑战和更改。相反,我们让 SELinux 阻止访问并查看应用程序的反应。根据应用程序的错误日志记录或应用程序的行为以及通过日志看到的 AVC 拒绝,我们可以很好地了解真正需要哪些权限。
归档时间: |
|
查看次数: |
363 次 |
最近记录: |