SELinux 干扰 sss_cache

SELinux 干扰 sss_cache

系统:

  • HP Pavilion 电源笔记本电脑 15-cb0xx
  • 启用集成显卡的 Intel i7-7700HQ(无法在 BIOS 中关闭)
  • 软呢帽28
  • NVIDIA GTX 1050(移动)

我使用dnfdragoraGUI 更新了大约 119 个软件包(我有一段时间忘记更新了:/)。在某个时候我收到了来自 SELinux 的通知:

SELinux is preventing sss_cache from write access on the directory /var/lib/sss/db/

我仔细研究了一下/var/log/messages/var/log/audit/audit.log发现了 SELinux 告诉我的同样的东西。

当这一切都结束后,我注意到事情进展得有点慢,所以我重新启动了。重启速度较慢,在加载 Fedora 徽标、加载登录 GUI 以及加载桌面时尤其明显。额外的重新启动并没有解决任何问题。

通过查看联机帮助页,sss_cache我了解了它的主要功能,以及它与系统安全服务守护程序 (SSSD) 的配合使用。

SELinux 对话框告诉我的内容如下: 在此输入图像描述

我知道这将通知维护人员潜在的错误,并且策略更改将阻止 SELinux 将来对 sss_cache 发出警报。我对 SELinux 一无所知,只知道它为 Linux 系统提供了添加/可配置的安全功能。然而我还是不明白为什么这种情况发生了,或者是否有其他可能更好的解决方案。我也不清楚这是否会解决我注意到的减速问题。

谁能告诉我:

  1. 为什么会发生这种情况?我可以猜测 SELinux 认为与 SSSD 相关的任何内容都非常需要保护,但为什么它不知道有一个与 SSSD 一起使用的实用程序?
  2. 我应该报告错误并创建本地策略模块,还是其他什么?
  3. 我是否应该撤消导致这一切的事务并以较小的组更新包?它甚至可以解决问题吗?
  4. 这是否会导致我上面提到的速度下降问题?我通过使用虚拟机(特别是在 VirtualBox 中扩展存储空间)知道,保留旧条目/etc/fstab可能会减慢启动速度,因为系统正在寻找不存在的东西。这里发生了类似的事情吗?

我不愿意在没有额外信息的情况下只按照屏幕上的文字去做。我不想在没有意识到的情况下在弹坑上贴上创可贴。

(根据要求提供其他信息):我应该说明:/var/lib/sss/db/是一个目录。

ls -Z /var/lib/sss/输出db/system_u:object_r:sssd_var_lib_t:s0

摘录自audit.log(包括夹在两个相关行之间的可能不相关的行):

type=AVC msg=audit(1543865969.237:241): avc:  denied  { write } for  pid=18065 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0
type=GRP_MGMT msg=audit(1543865969.239:242): pid=18062 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:groupadd_t:s0 msg='op=modify-group acct="rpcuser" exe="/usr/sbin/groupmod" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1543865969.264:243): avc:  denied  { write } for  pid=18067 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0

输出ls -Z /usr/sbin/sss_cache(通过 找到的位置which sss_cache):

system_u:object_r:bin_t:s0

事实证明“详细信息”窗口有很多信息: 在此输入图像描述

答案1

好像一个错误Fedora 的 SELinux 政策。

在修复发布之前,您可以使用audit2allow生成的策略或错误报告中的策略来允许访问。

相关内容