我正在分析一些专有软件来构build一组权限需求和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模式并logging所有AVC拒绝以开发策略模块可能会导致在此类策略中包含错误的权限集。
一个例子可能是这样的：假设这个专有软件的正常操作需要一个域转换 ，在宽容模式下，转换不会发生，并且它看起来像源域需要所有权限logging为AVC拒绝（ Sven Vermeulen的SELinux食谱包含这个潜在问题的几个参考）。
为专有软件创build策略模块的更好方法是首先维护SELinux执行模式，以确保授予最小权限 。
接下来是研究软件，无论是在线（有文件？）和离线（ ss ， strace ， ipcs ，…）来详细确定其架构devise，即，但不限于：
文件，这些文件也应该分成子组（configuration，事务，日志等）
进程，服务（软件是否有systemd / upstart / init脚本？）
networking连接（入站和出站stream量，端口…）
用户，组
有了这些信息，您就可以开始制定该软件的政策。
您将需要：
创build一个定义涉及的所有文件的安全上下文的filecontexts文件
根据文件，进程，端口，用户，域转换之间的所有交互创build一个定义您的域的接口文件…
创build一个types执行文件，描述哪些用户被授予对上述域的访问权限以及实际的规则
编译并加载它，检查AVC拒绝，debugging和增强您的策略。 冲洗并重复。
从上面提到的这本书中，最后一句话是：
一些策略开发者喜欢运行应用程序允许模式（通过以宽容模式运行整个系统或者将该特定域标记为允许域），注册所有已执行的访问（通过AVC拒绝）并基于该信息增强策略。 虽然这可能会带来更快的工作策略，但是这些开发人员也会冒险为自己的策略增加太多的权限，这是很难挑战和稍后改变的。 相反，我们让SELinux阻止访问并查看应用程序如何反应。 根据应用程序的错误日志logging或应用程序的行为以及通过日志看到的AVC拒绝，我们可以很好地了解真正需要的权限。