我正在尝试编写一个 SELinux 策略,该策略在安装后将禁止不受限制的(或另一个可以选择的)用户任何后续的 SELinux 策略安装。似乎有几种方法可以做到这一点:
至于第一个结论,我正在尝试使用“domain_auto_trans”宏,但是这个宏不适用于低于 25 的策略版本。我有 24。虽然我能够在策略版本 28 上检查它并且它按需要工作。顺便说一句,它看起来像这样
policy_module(semanage_access_deny_label_B, 1.0.0)
require {
type unconfined_t, semanage_exec_t, semanage_t;
role object_r;
}
domain_auto_trans (unconfined_t, {semanage_exec_t semanage_t}, user_t);
第二个结论的 TE 文件如下所示
policy_module(semanage_access_deny, 1.0.0)
require {
type unconfined_t;
role object_r;
class security { compute_av compute_user compute_relabel
compute_create setenforce check_context load_policy setbool };
}
allow unconfined_t self: security compute_user;
neverallow unconfined_t self: security { compute_av setenforce check_context load_policy setbool };
第一种方法仅适用于当前的 SELinux 版本,而第二种方法虽然成功编译并应用,但并没有达到我的计划(实际上它根本没有做任何事情)。因此,问题是如何编写一个策略,使其在安装后将禁止任何选定用户的任何后续 SELinux 策略安装,并且适用于当前和以前的 SELinux 版本?
答案1
您的第一个模块有问题: root 用户 in无限制_t仍然具有允许修改 selinux 策略的权限和规则。您的自定义策略仅应用新的自动转换semanage_exec_t到 用户_t。处理于用户_t域无法修改策略,因此semodule
,semanage
等会失败。然而,非信任域中的任何程序仍然可以修改该策略。另外,root 可以重新标记那些semanage_exec_t将二进制文件标记为任何不受限制的类型以运行它们。
您的第二个策略模块不执行任何操作,因为绝不允许规则经过编译器检查,不会在编译策略中产生任何规则。你不能使用绝不允许删除/黑名单规则已包含在加载的策略中(并且没有否定SELinux 策略语言中的声明,您可以以这种方式使用)。
如果存在冲突,策略编译应发出错误并失败允许和绝不允许规则。根据文档,绝不允许规则可以在策略模块中使用,但为了使检查有效,expand-check
必须将其设置为 1 semanage.conf
(可能是模块编译成功的原因)。
解决您的问题以防止修改加载的 SELinux 策略的一些方法:
使用
secure_mode_policyload
布尔值:布尔值,用于确定系统是否允许加载策略、设置强制模式和更改布尔值。
相似地
secure_mode_insmod
布尔值将阻止加载额外的内核模块。一旦打开,这些布尔值就无法在运行的系统上关闭(需要重新启动才能关闭)。配置用户到更有限的领域(例如用户_t),这不允许修改加载的策略。使用
su
/切换到 rootsudo
不会提升为更高权限的 SELinux 用户,并且会保留相同的 SELinux 强制限制。创建您自己的 SELinux 用户。您可以将其基于您的发行版提供的 SELinux 用户(下载您的发行版的策略源)。您可能应该考虑使用某些受限制的用户作为模板,而不是不受限制的用户,并且仅添加您需要允许的权限,以避免授予过于广泛的权限。
此外,如果您只需要授予一些有限的访问权限(转换/规则),您可以编写一个策略模块,向受限用户授予必要的访问权限。
答案2
当谈到“安装”新策略时,它归结为限制对谁可以“写入”和“重新标记”/etc/selinux/TYPE/policy/policy.* 文件的访问。
确定该目标的类型。使用 SELinux 策略分析套件来确定什么可以“写入”和“重新标记”该类型的文件。然后确保您不希望能够安装策略的任何进程都无法(直接或间接)访问该类型的文件。
此外,您可能还想确保您不希望能够安装策略的任何进程都无权访问“security setenforce”,并且没有物理访问权限。因为否则这些进程可能会绕过 SELinux。