DAC（文件权限）、ACL 和 MAC（SELinux）在 Linux 文件安全中扮演什么角色？

Question

我需要对 DAC、ACL 和 MAC 在 Linux 文件安全中扮演的不同角色进行一些澄清/确认/详细说明。

经过对文档的一些研究，这是我对堆栈的理解：

1. SELinux 必须允许您访问文件对象。
2. 如果该文件的访问控制列表（例如，setfacl，getfacl用于ACL安装）显式地允许/拒绝访问的对象，那么就不需要进一步的处理。
3. 否则，这取决于文件的权限（rwxrwxrwx DAC 模型）。

我错过了什么吗？是否存在情况并非如此？

Answer 1

当进程对文件执行操作时，Linux 内核按以下顺序执行检查：

1. 自主访问控制 (DAC)或用户指定的访问控制。这包括经典的 UNIX 样式权限检查和POSIX 访问控制列表 (ACL)。经典的 UNIX 检查将当前进程 UID 和 GID 与正在访问的文件的 UID 和 GID 进行比较，以了解已设置的模式（读/写/执行）。访问控制列表扩展了经典的 UNIX 检查，以允许更多关于权限控制的选项。

2. 强制访问控制 (MAC)或基于策略的访问控制。这是使用Linux 安全模块 (LSM) 实现的，这些模块不再是真正的模块（它们曾经是但已被删除）。它们启用基于其他模型的附加检查，而不是经典的 UNIX 样式安全检查。所有这些模型都基于一个策略，该策略描述了在哪种情况下哪个流程允许进行哪些类型的操作。

这是 inode 访问（包括文件访问）的示例，以通过指向在线Linux Cross Reference 的链接来支持我的答案。给出的“ function_name(filename:line)”适用于 3.14 版本的 Linux 内核。

函数inode_permission（fs/namei.c:449）首先检查文件系统本身的读权限（sb_permission在fs/namei.c:425 中），然后调用__inode_permission（fs/namei.c:394）检查读/写/执行do_inode_permission( fs/namei.c:368 ) (DAC) 中的 inode 上的权限和 POSIX ACL ，然后security_inode_permission( security/security.c:550 ) 中的LSM 相关权限 (MAC )。

这个顺序只有一个例外（DAC 然后是 MAC）：它用于 mmap 检查。但这已经在 3.15 版本的 Linux 内核中修复（相关提交）。

Answer 2

DAC=自主访问控制
MAC=强制访问控制
ACL=访问控制列表

该ACL指定的控件通过控制的方法来施加，DAC或MAC。 MAC是明确的、集中控制的，并且不允许用户向对象授予权限，除非他们有明确的权限这样做，而DAC允许用户授予其他用户访问他们可以访问的对象的权限。

MAC ACLs 将始终首先应用于请求，如果访问被拒绝，则处理停止。如果允许访问，则DAC ACL应用 s，如果访问被拒绝，则处理停止。只有当sMAC和DAC ACLs 都授予访问权限时，用户才能访问他们请求的对象。

SELinux是MACLinux 的一个实现（还有其他的），而传统的rwx文件权限，结合拥有用户和组形成完整的DAC ACL. 该SELinux“政策”在本质上是MAC ACL。

Answer 3

抱歉狡辩，但我认为这里的一些答案可能不正确。直接来自 Fedora 的http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html：

在 DAC 规则之后检查 SELinux 策略规则。如果 DAC 规则首先拒绝访问，则不会使用 SELinux 策略规则。