4

我正在努力限制现有的复杂应用程序的功能，并且我一直在寻找一个可靠的来源来证明其中包含的权限cap_dac_override是cap_dac_read_search.

根据以下情况，情况确实如此，这似乎是合乎逻辑的capabilities(7)：

CAP_DAC_OVERRIDE
* 绕过文件读取、写入和执行权限检查。

CAP_DAC_READ_SEARCH
* 绕过文件读取权限检查和目录读取和执行权限检查；
* 调用 open_by_handle_at(2);
* 使用 linkat(2) AT_EMPTY_PATH 标志创建指向由文件描述符引用的文件的链接。

此外，我对能力检查跟踪器的实验证实这cap_dac_override应该足够了。cap_dac_read_search似乎在cap_dac_override每次执行读取访问之前都会进行检查。

我还在grsecurity 论坛上找到了以下帖子，不幸的是，这些帖子仅涉及/proc：

对于这种情况，上游内核的工作方式是首先检查 CAP_DAC_OVERRIDE，然后检查 CAP_DAC_READ_SEARCH。

cap_dac_read_search如果我想授予我的应用程序对整个文件系统的完全读取访问权限，我仍然不确定是否完全安全。我完全知道cap_dac_override另外授予写权限，我想要那个。

是否有可能在内核的某个地方有一个地方只检查 forcap_dac_read_search而不是 for cap_dac_override？

为了安全起见，我应该同时包含这两种功能还是cap_dac_read_search在这种情况下完全多余？

4

2 回答 2

4

不它不是。CAP_DAC_OVERRIDE只允许忽略文件的权限位。CAP_DAC_READ_SEARCH允许忽略读取权限位，并且还允许执行open_by_handle_at可用于在容器 chroot 外部读取的系统调用。

实际应用见https://github.com/gabrtv/shocker。

如果您的应用程序只需要完全访问文件系统，那么CAP_DAC_OVERRIDE正如您已经得出的结论。

于 2020-01-26T15:31:07.947 回答
0

经过一些额外的验证和实际测试后，似乎确实cap_dac_override是cap_dac_read_search.

当cap_dac_read_search从相关应用程序中删除时，没有一个操作因权限被拒绝而失败。

于 2018-03-05T18:08:33.760 回答