☰

SELinux“训练​​”（宽容模式日志）

tag-icon • tag-icon selinux
SELinux“训练​​”（宽容模式日志）

好吧，我一直在浏览各种文章和视频。他们都说相同的基本内容：从默认策略开始，以宽容的方式运行以查看需要修复的内容。然后修改您的策略以解决潜在的问题。然后重新开始严格执行。

在这些参考文献中，他们建议我运行ausearch以获得更简化版本的audit.log。所以我尝试了一份这样的报告：

type=PROCTITLE msg=audit(03/27/2015 02:58:34.764:439) : proctitle=/bin/sh 
type=SYSCALL msg=audit(03/27/2015 02:58:34.764:439) : arch=x86_64 syscall=getxattr success=no exit=-61(No data available) a0=0x1fef030 a1=0x7fc0dbf2ef9f a2=0x7fff6aaa1da0 a3=0x84 items=0 ppid=1 pid=3861 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-logind exe=/lib/systemd/systemd-logind subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(03/27/2015 02:58:34.764:439) : avc:  denied  { getattr } for  pid=3861 comm=systemd-logind name=kvm dev="devtmpfs" ino=11755 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kvm_device_t:s0 tclass=chr_file permissive=1

很难弄清楚这条消息在说什么，尤其是当我面对数百条这样的消息时。

我看过一些文章，其中说将结果传送到ausearchto audit2allow。这似乎相当于每次弹出确认框时按下接受按钮。它还假设该消息是由错误引起的，而不是某个试图闯入的黑客。

那么有人可以建议一种合理的方法来分析 SELinux 宽容模式的“输出”吗？

答案1

很多时候，您会收到一些信息，并需要挑选出与您的目的相关的信息。例如，当您strace编写程序时，您将拥有大量输出，并且仅将与您查看输出的原因相关的部分归零strace。

审计日志遵循类似的原理。让我们看看你的：

类型=PROCTITLE msg=审计(03/27/2015 02:58:34.764:439) : proctitle=/bin/sh

不太令人兴奋。它为您提供时间戳和可执行文件的值proctitle（通常是进程名称）。不过，不太清楚为什么logind要把它作为一个程序标题。

类型=AVC msg=audit(03/27/2015 02:58:34.764:439) : avc: 拒绝 { getattr } for pid=3861 comm=systemd-logind name=kvm dev="devtmpfs" ino=11755 scontext=system_u :system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:kvm_device_t:s0 tclass=chr_file 许可=1

这是实际的 SELinux 错误消息，也是您最应该关心的事情。这type=AVC就是它的本质。AVC代表access vector cache 这是一个 SELinux 组件。

需要注意的重要部分是该denied节中的内容（在本例中getattr），它告诉您程序为了被拒绝而专门做了什么。之后，我们查看源上下文（又名scontext），这将使您了解一般类别在这种情况下，完整的上下文被system_u:system_r:system_dbusd_t缩短为唯一具有实质性意义的部分（99％的时间）system_dbusd_t。对我们得到的目标上下文做同样的事情kvm_device_t。comm和字段pid非常重要且显而易见。异常发生在systemd-logindPID为3861的运行程序上。

所以把它放在一起我们正在systemd-logind运行并尝试对上下文为 的文件system_dbusd_t执行某种操作。getattrkvm_device_t

管理员知道这意味着您应该做什么。对于 SELinux 来说，它只知道其政策不允许这样的事情，因此它会向您提供详细信息，以便您可以自己进行调用。

type=SYSCALL msg=audit(03/27/2015 02:58:34.764:439) : arch=x86_64 syscall=getxattr success=no exit=-61(无可用数据) a0=0x1fef030 a1=0x7fc0dbf2ef9f a2=0x7fff6aaa1da0 a3= 0x84 items=0 ppid=1 pid=3861 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(无) ses=unset comm=systemd-logind exe=/lib/systemd/systemd-logind subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)

就您的呈现方式而言，这有点不按顺序，但我将其放在后面，因为这样可以更轻松地理解您应该如何阅读它。这type=AVC是重要的部分，但它通常会记录失败的实际系统调用，以便您可以获得更多详细信息。

例如，给定程序名称，我们知道它systemd-logind是什么，但如果它更模糊，exe=/lib/systemd/systemd-logind可能会让您确定哪个程序导致了错误。如果您不确定为什么有问题的可执行文件被启动，诸如auid（loginuid进程的）或 之类的信息也可能是有用的信息。uid

希望有帮助。如果您有任何疑问，我会更新我的答案。

编辑：关于你最后一点的另一件事。通常，您可以查看策略audit2allow生成的内容并了解它所带来的变化。在您插入策略模块之前，它实际上不会应用更改。因此，您仍然可以生成它，然后在文本编辑器中查看它，看看它是否是您希望允许发生的事情。可能比直接阅读来追踪细节更快audit.log。

相关内容