☰

如何识别 Android 上的 dac_override 原因？

tag-icon • tag-icon android selinux
如何识别 Android 上的 dac_override 原因？

我正在开发一些 Android 自定义项，我正在编写的一个应用程序会导致dac_overridedmesg 中的结果如下所示：

type=1400 audit(499405.329:16): avc: denied { dac_override } for 
pid=1103 comm="my_tool" capability=1 scontext=u:r:my_tool:s0
tcontext=u:r:my_tool:s0 tclass=capability permissive=1

我知道导致问题的可执行文件（它是my_tool），并且我知道这dac_override意味着该可执行文件没有执行某些操作的传统 Linux 权限，但我不知道尝试了哪个操作以及尝试了哪个文件。我怎样才能找到答案？

另外，作为一个附带问题，我认为 SELinux 的名称和行为是否dac_override有能力覆盖传统的 Linux 权限违规？

答案1

系统化的方法是

1) 将 SELinux 设置为通过setenforce 1. SELinux 违规应该会使相应的系统调用my_tool失败。您可以使用getenforce它来验证是否成功。

2) 运行my_toolwithstrace来识别失败的系统调用，例如strace my_tool 2>&1 | grep '= -'.

就我而言，我有以下违规行为：type=1400 msg=audit(4816808.488:3): avc: denied { dac_override } for pid=123 comm="my_tool" capability=1 scontext=u:r:my_tool:s0 tcontext=u:r:my_tool:s0 tclass=capability permissive=0

跑步strace my_tool 2>&1 | grep '= -'给予

openat(AT_FDCWD, "/some/file", some_mode) = -1 EINVAL (Invalid argument)

使用确认该文件在运行时由用户ls -l /some/file拥有，并且该文件的 DAC 权限不允许其他用户访问。当然，用户绕过了这个限制，但它在 SELinux 中产生了违规（systemmy_toolrootrootdac_overwrite参考）。因此，关于您的最后一个问题：SELinux 不允许绕过传统的 DAC 权限，但它甚至可以用于对用户强制执行这些权限root。

当然，这种方法的有效性在某种程度上取决于 的复杂性my_tool，即它在正常操作期间处理多少其他失败的系统调用。

答案2

一般建议启用完整的系统调用审核使用此类 AVC 获取一些路径信息。不过android好像不支持。因此，使用straceor跟踪系统调用perf trace并查找与失败的文件相关的系统调用是下一个最好的事情。

也可以看看

调试 DAC_OVERRIDE（在 Android 上），2019 年发布，描述了修改 Android 内核以在 AVC 发生时获取一些调用堆栈。这当然有点侵入性，并且只有在您无法使用的情况下似乎才值得perf- 因为perf谁可以只安装探测器来获取类似的信息。

相关内容