我需要对DAC,ACL和MAC在Linux文件安全性中扮演的不同角色进行一些澄清/确认/阐述.
经过文档的一些研究,这是我对堆栈的理解：
> SELinux必须允许您访问文件对象.
>如果文件的ACL(例如,ACL安装的setfacl,getfacl)明确允许/拒绝访问该对象,则不需要进一步处理.
>否则,它取决于文件的权限(rwxrwxrwx DAC模型).
我错过了什么吗？是否存在不是这种情况？
解决方法:
当进程对文件执行操作时,Linux内核按以下顺序执行检查：
> Discretionary Access Control (DAC)或用户口述访问控制.这包括经典的UNIX样式权限检查和POSIX Access Control Lists (ACL).经典UNIX检查将当前进程UID和GID与正在访问的文件的UID和GID进行比较,以确定已设置的模式(读/写/执行).访问控制列表扩展了经典UNIX检查,以允许有关权限控制的更多选项.
> Mandatory Access Control (MAC)或基于策略的访问控制.这是使用Linux Security Modules (LSM)实现的,它们不再是真正的模块(它们曾经是,但它被删除).它们基于除经典UNIX样式安全检查之外的其他模型启用附加检查.所有这些模型都基于一个策略,该策略描述了在哪种上下文中允许哪种操作.
下面是inode访问(包括文件访问)的示例,用于通过指向在线Linux Cross Reference的链接来支持我的答案.给出的“function_name(filename：line)”适用于3.14版本的Linux内核.
函数inode_permission(fs/namei.c:449)首先检查文件系统本身的读取权限(fs/namei.c:425中的sb_permission),然后调用__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检查.但这已经在Linux内核的3.15版本(relevant commit)中得到修复.
【说明】：本文章由站长整理发布，文章内容不代表本站观点，如文中有侵权行为，请与本站客服联系(QQ:254677821)！