☰

是MAC还是DAC

tag-icon • tag-icon linux security acl access-control lsm
是MAC还是DAC

我在查看 LSM 属性/上限实现的实用程序或使用时遇到问题。

我整理了一些伪代码片段来尝试表达我的担忧和问题。它是根据 (p 3) 中的图表建模的 https://www.kernel.org/doc/ols/2002/ols2002-pages-604-617.pdf

内核访问检查（大约）和 LSM 调用：

DAC
op:__?   // ? what operation would pass a DAC check yet not the LSM hook ?
file:___
perms:  u.. g.. o.. 
euid:100
egid:500


OK  ----> LSM hook ( args ) 

        1) I don't know the args here, 

        2) Regardless of the args I can't make out what operation would pass a DAC check
           and be restricted here and why? 

           ? read file ?      allready handled by DAC

           ? network device ? allready handled by DAC, it's a file.

           ? execution ?      x bit , allready handled

           ? executing a specific function ? no function call references here

           ? executing a specific syscall ? would be handled on exec on the target (read, write etc..)

           ?  
           **What exactly can the LSM hook accomplish here that DAC hasn't allready addressed ??**


            Answers are welcome.
            sp

我读过有关尝试让编码人员不使用 setuid root 并使用某些 CAP 属性来使此工作实现更安全的特权升级的讨论，但我个人不是依赖行为改变的专家，也不是依赖钩子权限检查来确保机器上运行的代码的完整性，我怀疑我是孤独的。

我也读到这不是 LSM 的意图这里

它解决了设计问题，但对于当前 DAC 权限检查的精确用途仍然模糊。它讨论了为什么钩子在它们所在的位置，但没有讨论如何有效地使用它们来完成比 DAC 更重要的事情。

答案1

功能是类似于 setuid 的权限升级层，但粒度更细；例如，程序无需完全根级别访问即可获得 CAP_NET_RAW 权限。这是“最低必要权限”和服务器控制方面向前迈出的一大步，因此好的，但它不是强制访问控制；这是特权升级。

SELinux 研究标签和标签之间的权限的概念。因此，您可以为httpd进程授予“Web 服务器”标签，为 Web 树中的所有文件授予“Web 文件”标签，然后授予“带有 Web 服务器标签的进程只能读取 Web 文件”。

此标签构造位于现有文件系统权限和 ACL 权限之上。即使文件是世界可读的，SELinux 也可以否定访问它。要授予进程访问权限，它需要传递 DAC（文件系统权限）和 MAC (SELinux) 权限。

从商业角度来看，eTrust Access Control（或 Control Minder，或者现在的任何名称；最初搜索引擎优化系统）是另一个MAC层。这不使用标签来控制内容，但允许路径定义的规则，并且如果在规则中使用它们，则将校验和程序。这比 SELinux 标签更灵活（并且是跨平台的；例如 Solaris、AIX、HPUX）。同样，它位于文件系统 DAC 层之上；双方都需要批准该请求。

相关内容