@
james122333 尽管访问控制在描述计算机安全系统的文献中比较流行，访问控制既不是通用的安全(safety)也不是系统安全（或者说安保）(security)专属的特性，而是一种要求系统具有特定属性时的实现手段。
对上层系统的需求描述来讲，可预期应当是自然的，但实现上不可能无限担保，总有一些前提。逻辑上任何一个不满足假设前提的非预期行为的脆弱性都可以导致一整套机制实效。
例如，基本上重大的软件安全漏洞都源自于安全软件的实现违反可预期的语义保证的程序行为。符合语言规范要求的正确编码就是这里的一种前提。
如果真要用于安全目的，笼统的访问控制的效果除了“可预期”（但是因为许可证经常不担保承担责任，出 bug 嘛……），几乎等于没有。
即便说的是 MAC ，也要求区分正确不同的敏感性才可能提供有意义的保证。当然，不是说不满足 MAC 就无所谓安全，但说实话就算具有 MAC 的系统，也可能只提供很入门级的系统安全性。
对控制整个计算机的操作系统，没有 MAC 意味着系统管理员基本没什么手段最终可以区分针对系统资源利用的无意和恶意的历史行为，在此之上的保护仅仅是防止手贱的程度了。
所以光是考虑对非专业用户的认知友好（避免误导）上，这类访问控制还不如彻底排除出安全目的，就像设计用于摘要的散列函数不应当被视为“加密”一样。
处理文件权限的要求是软件接口的要求，包括 API 和 UI 。没什么实际应用故意去利用文件权限来编码无关的业务信息，所以如果放弃基于文件权限的访问控制，这就是多余的。考虑到上下文（比如沙箱）可以代替文件作为更强力的安全措施，这原则上不会损害安全性。
另一方面，摈弃权限的思路，特定的属性反而可以编码原先没有不能充分被利用的更上层信息。例如，限制写访问不作为访问控制，而是明确作为文件的只读属性的实现，可以类似 PL 中的对象引用的只读访问限制；如果能假定上下文而确保只读访问不和其它数据访问（比如并发写内容或者修改属性）冲突，传统 PL 上的优化也可以适用于 VFS 及其它持久对象系统。对只读属性，典型的优化是常量传播。结合这些优化，可以轻易地实现文件系统去重这样的高级功能，而不用单独重新实现（除非是为了性能调优进行特化）和验证。
遗憾的是，传统的操作系统设计并不适合这种实践——非但缺乏普遍可编程的上下文，还普遍不能排除 TOCTTOU 这种并发访问冲突。
（作为实现细节，虚存分页机制上的权限可以继续维持 RWX 的基础设计以避免开销；这不和上层的高级语言语义或者持久存储要求的属性矛盾。）
考虑这种遗憾的相当大一部分，来自系统和应用开发者的墨守成规（不愿意承认上下文的必要性），现在来看，UNIX 权限这种设计，还不如一开始就没存在过。
多用户自然还是得有的，但不应该和 UNIX 权限那么强绑定：而是更接近 NT 的 SID 这样的间接抽象；虽然 SID 用起来的体验嘛……
@
tomychen 这里的阻碍很大程度上来自 UNIX 等上古系统设计的思维惯性，使系统设计和维护人员乃至大多数应用开发人员都难以适应范式转移，而不是具体维护工作的开销（虽然这对绝大多数组织已经够要命了）。
更根本地，这可以追溯为主流的设计人员没有理解清真正的需求，而直接偷懒复用了旧的设计，恰好旧的设计因为时代局限性等历史原因也没有解决一系列关键问题。这同时是懒惰和教条主义的体现。
这种消极的懒惰不是强到一定的地步，TOCTTOU 这种低级的问题不可能不被处理掉，而不是 POSIX.1-2008 这样一堆 at 补丁就能凑数了。
所谓设计模式是另外一种业界体系性缺陷的集中体现：
www.v2ex.com/t/835769#r_11427195 ，所以看起来像设计模式味儿的设计，本身就暗示存在一些没解决的糊涂问题。
老实说，UNIX 这种一切皆文件的设计和 OOP 语言所谓一切都是对象的设计是类似的问题，比所有所谓的设计模式都高层一些，更应当是架构上的。
即便如此，这里也是高下立判。OOP 类似主张的主要问题是根本没拎清楚“对象”本来就应该有的含义，重要原则（设计上鼓吹 LSP ）其实也是老调重弹（这其实就是许多更传统多态类型系统上的公理），而在更具体设计（类型系统上基于继承这种序结构实现的包含多态）多少还有点进步意义；反观文件，则更像是需求假设破碎却又应对不了新的需求（要求常规文件和目录以外新的类型的持久对象）之后的近乎不作为放任自流的结果罢了，在古典设计之后基本就不存在实质的创新。
SELinux 的出发点（看到现有系统设计不足，应对真实安全保证的需求很无能）没太大问题，复杂主要也是来自安全保证需求自身。
但另一方面还有它是在传统 UNIX 的 VFS 上的强行修补的原因。如果 UNIX 权限不存在，那么结果大约会好那么一些。
（嘛，只是好一些，因为缺乏像样的 UI ，也确实太复杂了，并且这玩意儿文档也不大好找，具体配置非常依赖用户自己发挥； Linux 桌面系统要是开箱可用不折腾也就算了，Android 手机我是折腾吐了弃疗了。另外 Android 的魔改权限正是我黑 UNIX 的动力之一，即便折腾起来比 SELinux 仍然容易多了……）
没有后退的余地会让开发者使 UI 更加友好易用。这才是最终能使这种机制普遍实用化的动力，而现在做得还是很不够。排除掉上面的来自开发者懒惰和墨守教条的原因，还有个重要因素是最终用户推动不够。大多数用户甚至都未必知道这个难用到什么程度，知道“难关闭”（但这姑且算是个预期中的 feature……）就不错了。
这方面我强调：不好用，也尽量不要回避，否则只会恶性循环而无法改善现状。
TOMOYO 这样的尝试对引入安全保证的能力是好事，但是长期来讲，仍然不算受到足够的重视（这个应该 2.6 时代就有了，长期也没啥存在感）。
Linux 社区，特别是 Linux Torvalds 本人，传统上并不怎么在乎安全需求（传说中的 masturbating monkeys……）。
独立于内核之外的 Grsecurity/PaX 是早年一个比较著名的例子。
当然，其实我也没那么在乎……至少没在乎到像 old school hacker 一样亲自糊个类似 LSM 的东西；毕竟成本过于离谱。
我更在乎的是不合时宜的旧设计无法被移除，并且越来越没戏。
毕竟，软件安全的一个持久的重要未决问题是：现有代码写得太长了，导致看不完而没法完成审计。