☰

DAC（文件权限）、ACL和MAC（SELinux）在Linux文件安全中起什么作用？

tag-icon • tag-icon linux permissions selinux acl
DAC（文件权限）、ACL和MAC（SELinux）在Linux文件安全中起什么作用？

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

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

  1. SELinux 必须允许您访问文件对象。
  2. 如果文件的 ACL（例如，setfacl对于getfaclACL 安装）明确允许/拒绝访问该对象，则不需要进一步处理。
  3. 否则，取决于文件的权限（rwxrwxrwx DAC 模型）。

我错过了什么吗？是否存在这种情况不是案子？

答案1

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

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

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

这是一个索引节点访问（包括文件访问）的示例，通过在线链接来支持我的答案Linux交叉参考。给出的“ 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(中的 inode 上的读/写/执行权限和 POSIX ACLfs/namei.c:368) (DAC)，然后是security_inode_permission(安全/安全.c:550）。

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

答案2

数模转换器=自主访问控制
苹果=强制访问控制
前交叉韧带=访问控制列表

ACL 指定要通过控制方法（DAC 或 MAC）应用的控制。 MAC 是显式的、集中控制的，不允许用户向对象授予权限，除非他们有明确的权限，而 DAC 允许用户向其他用户授予对他们可以访问的对象的访问权限。

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

SELinux 是 Linux（还有其他）的 MAC 实现，而传统的rwx文件权限与所属用户和组相结合形成了完整的 DAC ACL。 SELinux“策略”本质上是 MAC ACL。

setfacl扩展了基本文件系统 ACL，以允许为多个用户或组分配文件和目录的 ACL。这也是 DAC 实现，因此在 SELinux MAC ACL 之后应用。

答案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:

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

相关内容