SELinux 用户角色陷阱

SELinux 用户角色陷阱

新的安全策略要求 RHEL 系统上的系统管理员必须映射到 或sysadm_U角色staff_u,而“普通”用户必须映射到user_u角色。在此之前,我们使用开箱即用的配置,所有用户都拥有unconfined_u.

在运行一个将系统管理员组映射到sysadm_u角色的小测试后,我发现这些用户最初无法通过 SSH 登录。在深入研究 SELinux 策略源之后,我发现ssh_sysadm_login需要设置一个布尔值 来允许此功能。

我还尝试将同一组映射到该staff_u角色。这个角色恰好能够很好地进行 SSH,但巧合的是,我发现他们无法执行 SSH 端口转发操作。我再次找到了布尔值,user_tcp_server解决了这个问题。

无论如何,这两个对常见(关键)管理员功能的直接影响让我担心在推出此更改时我可能会遇到哪些其他“陷阱”。有人指出,这一变化可能会影响已部署的应用程序,从而使该问题的范围变得非常广泛。因此,让我们将答案集中在人们期望在影响核心功能的基础操作系统安装上看到的影响(例如前面提到的 SSH 问题)。

答案1

如果有人在这些政策更新后对此有疑问:

staff_u应分配给通过 SSH 进入该盒子的用户,包括管理员。您进行分配是staff_u因为默认情况下sysadm_u由于 SELinux 布尔值而无法通过 SSH 连接到计算机ssh_sysadm_login

在您的 中/etc/sudoers,您需要添加以下内容,以便使用sudo/的用户在提升时su将获得sysadm_u用户和角色:sysadm_r

%wheel ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL

这些(及相关)指南的最新版本位于 2021 年 10 月 27 日发布的 V3R5 RHEL 7 STIG 中,漏洞 ID V-250312、V-250313、V-250314 和 V-204444

至于“陷阱”,如果您的计算机之前运行时没有 SELinux 用户映射,请确保重新启动服务,否则可能会出现问题。staff_u无法向前移植就是一个例子,这会因组织而异。setroubleshoot-server我们将成为您的朋友,根据您的需求定制这些政策。我还推荐 Gentoo wiki 的SELinux 教程,因为它们是我迄今为止读过的最好的一些。

相关内容