PDF操作系统的访问控制可扩展性的十年
移动和嵌入式设备的开源安全基础
Robert N. M. Watson，剑桥大学计算机实验室
讨论操作系统安全就如同惊叹于已部署的访问控制模型的多样性：Unix 和 Windows NT 多用户安全；SELinux 中的类型强制 (Type Enforcement)；反恶意软件产品；Apple OS X、Apple iOS 和 Google Android 中的应用程序沙箱；以及面向应用程序的系统，如 FreeBSD 中的 Capsicum。这种多样性是 1990 年代狭隘的 Unix 和 NT 现状向安全本地化——操作系统安全模型适应于站点本地或产品特定需求——惊人转变的结果。
这种转变受到三个变化的推动：无处不在的互联网连接的出现；从专用嵌入式操作系统迁移到通用操作系统以寻求更复杂的软件栈；以及从多用户计算向具有复杂应用程序模型的单用户设备的广泛转移。可扩展的访问控制框架促进了这种转变，这些框架允许操作系统内核更容易地适应新的安全需求。
TrustedBSD 强制访问控制 (MAC) 框架就是这样一种可扩展的内核参考监视器框架，它从 2000 年开始开发，并于 2003 年在开源 FreeBSD 操作系统中发布。本文首先描述了访问控制可扩展性的背景和挑战以及高层框架设计，然后转向在几个基于框架的产品中部署安全策略的实践经验，包括 FreeBSD、nCircle 设备、Juniper 的 Junos 以及 Apple 的 OS X 和 iOS。虽然可扩展性是这些项目的关键，但它们促使框架本身发生了相当大的变化，因此本文还探讨了框架如何（以及如何没有）满足每个产品的需求，并最终反思了操作系统安全的持续演变。
操作系统设计中的一场静悄悄的革命
在过去的 20 年里，嵌入式和移动操作系统发生了巨大的变化：设备获得了运行通用操作系统的 CPU 功率；它们被放置在无处不在的网络环境中；它们需要支持成熟的软件栈，包括第三方应用程序；并且它们发现自己暴露在由强大的经济动机驱动的恶意活动中。供应商在现有操作系统（通常是开源的）的基础上构建，以避免从头开始创建。这提供了成熟的应用程序框架和复杂的网络栈，这两个领域都是当时“嵌入式操作系统”的弱点。早期的例子是 Juniper 的 Junos，它是 FreeBSD 的一个版本，于 1998 年为路由器控制平面进行了适配。到 2007 年，当基于 Linux 的 Google Android 和部分基于 Mach 和 FreeBSD 的 Apple iOS 可用时，这一趋势已经实现，从而改变了智能手机市场。
所有这些环境的共同点是关注安全性和可靠性：当第三方应用程序部署在从 Junos（通过其 SDK）到 iOS 和 Android 应用商店的系统中时，沙箱化变得至关重要，首先是为了防止变砖（由于故障或滥用而将设备变成一块砖头），然后是为了约束恶意软件。移动电话访问在线购买，以及最近的银行和支付系统，也加强了这一趋势。因此，操作系统安全的角色已经从保护多个用户免受彼此侵害转变为保护单个操作员或用户免受不可信应用程序的侵害。嵌入式设备、移动电话和平板电脑现在是利益交汇点：消费者、电话供应商、应用程序作者和在线服务等许多不同方的利益必须在为另一个地点和时间设计的操作系统的帮助下进行调解。
访问控制框架
操作系统开发人员必须满足设备供应商的需求，他们需要从路由器和防火墙加固到移动电话应用程序沙箱的一切。操作系统供应商准确地观察到历史可信操作系统的艰难采用路径，这些操作系统的强制访问控制方案存在可用性差、性能差、可维护性差以及——也许最关键的是——最终用户需求不足的问题。同样，他们看到了许多有希望的新安全模型在研究中，每个模型都具有未知的可行性，这表明没有单一的访问控制模型能够满足所有需求。安全本地化的这种实际情况直接推动了可扩展的访问控制。
过去 20 年的研究已经明确了对参考监视器的需求——一个自包含、不可绕过且紧凑（因此可验证）的访问控制中心化。2 到 1990 年代初期，这个概念已经与封装的概念相结合，出现在 Abrams 等人的通用访问控制框架 (GFAC)1 中，并在 1990 年代后期出现在 Ott 的基于规则集的访问控制 (RSBAC)14 和 Spencer 等人的 Flask 安全架构17 中。主流操作系统供应商直到 2000 年代初期才采用这些方法，FreeBSD 上的 MAC 框架22 和不久之后的 Linux 安全模块 (LSM)23 才出现。在这两种情况下，一个关键的关注点是在不承诺像早期可信系统那样固定策略的情况下支持第三方安全模型。
MAC 框架
MAC 框架于 1999 年提出，其设计的第一份白皮书于 2000 年 6 月发布。20 它于 2003 年作为实验性功能出现在 FreeBSD 5.0 中——默认情况下编译输出，但可供早期采用者使用。2009 年的 FreeBSD 8.0 将该框架作为生产功能包含在内，编译到默认内核中。（其开发中的关键事件时间轴如图 1 所示。）
MAC 框架为内核访问控制增强问题提供了一个逻辑解决方案：一个能够表示许多不同策略的扩展基础设施，提供改进的可维护性并由操作系统供应商支持。与设备驱动程序和虚拟文件系统 (VFS) 模块类似，10 策略被编译到内核或可加载模块中，并实现良好定义的内核编程接口 (KPI)。策略可以增强访问控制决策，并利用通用基础设施（如对象标记）来避免直接内核修改和代码重复。它们能够跨广泛的对象类型（从文件到网络接口）强制执行访问控制，并与内核的并发模型集成。
强制策略
MAC 描述了一类安全模型，其中策略约束所有系统用户的交互。与自主访问控制 (DAC) 方案（如文件系统访问控制列表 (ACL)）允许对象所有者自行决定保护（或共享）对象不同，MAC 强制执行系统范围的安全不变量，而与用户偏好无关。研究文献描述了大量基于信息流和基于规则的模型的强制策略。
早期的强制策略侧重于信息流，需要在整个内核中普遍强制执行。多级安全 (MLS) 通过标记用户许可和数据机密性来保护机密性，从而限制流动。5Biba 完整性策略是 MLS 的逻辑对偶，保护完整性。6 这些模型维护主体和对象安全标签，其中包含机密性或完整性信息，并控制可能导致信息升级或降级的操作。
SRI International 的可证明安全操作系统 (PSOS) 设计包括对对象类型的强力强制执行，补充了能力保护。13 这演变为 Boebert 的类型强制 (TE)7 和 Badger 等人的域和类型强制 (DTE)4，它们已被证明具有影响力，TE 已部署在 SELinux11 和 McAfee 的 Sidewinder 防火墙中。这两种模型都灵活且细粒度，使用符号域和类型标记主体和对象。管理员控制的规则授权域之间的交互和转换。
最后，一类广泛的特定产品加固策略也相关；这些策略采用不太有原则的方法，提供对服务的直接控制，而不是抽象模型。
在访问控制可扩展性之前
在实施论文中，我们根据经验批评了当代技术
• 直接内核修改被用于大多数可信系统，无论是操作系统供应商（例如，Trusted Solaris）还是第三方扩展（例如，Argus Pitbull）发起的。跟踪上游操作系统开发是有问题的：扩展无法依赖公共的，因此更稳定的，应用程序编程接口 (API) 和 KPI——以及当时不太明显的，应用程序二进制接口 (ABI) 和内核二进制接口 (KBI)。上游变动经常会引发与安全扩展的设计和源代码冲突。保证也受到影响，因为为正确性辩护的负担完全留给了扩展编写者。
• 系统调用拦截广泛用于防病毒系统，过去也用于安全扩展产品和研究系统。9 内核并发性证明是一个特殊的挑战，我们已经证明了包装器和内核之间容易被利用的竞争条件。19
指导设计原则
访问控制可扩展性和鼓励上游和下游供应商参与的双重目标促使了 MAC 框架的几个设计原则
不要承诺特定的访问控制策略。 对于单一策略甚至策略语言没有共识；相反，在 C 代码中捕获策略模型。
避免特定于策略的内核入侵。 将内部结构封装在与策略无关的接口之后。这自然而然地导致了以对象为中心的设计——关于主体、对象和方法的访问控制检查。
提供与策略无关的基础设施。 这满足了访问控制工具之外的常见要求，例如标记和跟踪。
支持同时加载多个策略。 这样，策略的不同方面，可能来自不同的供应商，可以独立表达。例如，Trusted IRIX 和 Argus Pitbull 都采用了 MLS 来保护用户数据机密性，而 Biba 用于保护可信计算基础 (TCB)。组合必须是可预测的、确定性的，并且理想情况下是明智的。
强制执行有助于保证论证的结构。 这可以通过参考监视器分离策略和机制，并通过良好定义的 KPI 语义（例如，锁定）来完成。
为日益并发的内核设计。 策略不仅必须行为正确，而且还必须随着它们保护的功能而扩展。
MAC 框架的架构
如图 2 所示，MAC 框架是一个连接内核服务、策略和安全感知应用程序的薄层。控制从内核消费者传递到框架，再通过大约 250 个入口点（对象类型 x 方法）传递到策略
• 内核服务入口点允许子系统（例如，VFS）在相关事件和访问控制中与参考监视器框架交互。
• 策略入口点连接框架和策略，相对于相应的内核服务入口点添加显式标签参数。它们由策略生命周期事件和库函数补充。策略只需要实现它们需要的入口点。
• 应用程序使用标签管理 API 管理标签（在进程和文件等上）。
• DTrace 探针允许入口点跟踪、分析和工具化。8
总的来说，这些接口允许策略以可维护的方式增强内核访问控制。
入口点调用
为了理解这些层如何交互，让我们跟踪通过内核的单个文件写入检查。图 3 说明了vn_write，一个 VFS 函数，实现write和writev系统调用。mac_vnode_check_write内核服务入口点授权写入vnode (vp)，通过两个主体凭证fp->f_cred，它打开了文件，以及active_cred，它启动了写入操作。策略可以实现 Unix 能力语义 (fp->f_cred) 或 撤销语义 (active_cred)。vnode锁 (vp->v_lock) 在检查和使用期间都持有，保护标签状态并防止检查时到使用时的竞争条件。
从入口点排除的参数与包含的参数同样重要。例如，vn_write的数据指针 (uio) 被省略了，因为此数据驻留在用户内存中，并且不能相对于写入进行无竞争访问。整个框架中的类似设计选择阻止了不能通过内核同步模型安全表达的行为。
在可能的情况下，最好从内核子系统实现标记对象的角度出发，并且可以通过控制方法调用来强制执行策略。这种方法自然适合内核，内核采用面向对象的结构，尽管 C 中缺少语言特性。一旦识别出对象，放置入口点就需要谨慎：KPI 越细粒度，策略就越具有表现力——以策略复杂性为代价。调用站点越少，它们就越容易验证；但是，太少会导致保护不足。入口点设计还必须平衡将检查放置得足够深入以允许洞察对象类型，同时最小化特定抽象级别的强制点。
图 4 说明了mac_vnode_check_write，一个薄垫片，它断言锁、调用感兴趣的策略并触发 DTrace 探针。策略不被禁止直接访问vnode字段；但是，传递显式标签引用避免了在常见情况下将vnode结构布局编码到策略中，从而提高了 KPI 和 KBI 的弹性。
策略入口点调用，封装在MAC_POLICY_CHECK中，并非易事：必须同步对策略列表的访问以防止与模块卸载发生竞争，必须调用感兴趣的策略，并且必须组合结果。框架采用简单的组合元策略：如果任何策略返回失败，则拒绝访问（图 5）。在此示例中，Biba 的EPERM优先于包括 MLS 成功在内的其他几个策略结果返回。唯一的例外是稍后讨论的权限扩展。此元策略简单、确定性、可被开发人员预测，并且最重要的是，有用。
图 6 说明了 Biba 调用：Biba 检查其撤销配置，解包特定于策略的标签，并使用其支配运算符计算决策。
内核对象标记
许多访问控制策略标记主体和对象，以便支持访问控制决策（例如，完整性或机密性级别）。MAC 框架为内核对象、标签管理系统调用和文件标签的持久存储提供与策略无关的标签工具。策略控制标签语义——不仅是存储的字节，还有内存模型。例如，策略可以存储每个实例、引用计数或全局数据。
框架使用struct label表示标签存储，这对内核服务和策略都是不透明的（图 7）。在此示例中，Biba 将低完整性分配给新创建的套接字，从低进程继承该属性。但是，分区策略仅标记进程，而不标记对象。在对象类型支持元数据方案的情况下（例如，mbuf标记，其中包含每个数据包的元数据），使用这些标记；否则，标签指针将添加到核心结构（例如，vnode）。策略可以借用现有的对象锁来保护标签数据，如果同步模型支持的话。
从研究到产品
介绍了 MAC 框架的设计之后，让我们将注意力转向在 FreeBSD 衍生的商业或开源产品中找到的策略。表 1 和图 8 说明了几个此类策略模块、它们的功能足迹和发布日期。许多因素促成了这种转变的成功
对新访问控制的需求迫在眉睫。 经典的 Unix 模型未能满足 ISP、防火墙和智能手机的需求。与此同时，随着无处不在的网络和攻击者强大的经济动机，攻击威胁变得普遍。
框架的结构论证是正确的。 访问控制可扩展性是支持安全本地化的首选方式，可满足多样化的需求。
没有一种策略模型成为主导。 因此，必须支持多种模型。
硬件性能的提高增加了对安全开销的容忍度。 即使在消费类和嵌入式设备中也是如此。
开源技术转型有效。 FreeBSD 不仅为协作研究和开发提供了一个论坛，而且还为商业产品提供了一条管道。
自 2003 年以来，由于在产品中部署它的公司的贡献，该框架已经得到了显著发展。
FreeBSD
FreeBSD 是一个开源操作系统，用于构建在线服务、设备和嵌入式设备。在数据中心（Internet Systems Consortium、Yahoo!）、作为集成产品（NetApp 和 EMC Isilon 存储设备）的基础以及在嵌入式/移动设备（Juniper 交换机和 Apple iPhone）中都可以找到 FreeBSD 或其组件。它的起源可以追溯到 1970 年代和 1980 年代开发的伯克利软件发行版 (BSD)。12 BSD 开创了许多核心 Unix 技术，包括快速文件系统 (FFS) 和伯克利 TCP/IP 栈和套接字 API。BSD 许可证及其变体（MIT、CMU、ISC、Apache）通过允许不受限制的商业用途来鼓励技术转型。FreeBSD 的多样化消费者既推动了安全本地化，又是安全本地化的完美目标。
MAC 框架是一个复杂的软件；虽然框架本身只有 8,500 行代码，参考策略中有 15,000 行代码，但它与数百万行代码的内核集成在一起。向生产的过渡依赖于几个因素，包括对调解的信心日益增强以及对社区关于设计、兼容性和性能的反馈的回应。该框架最初在 FreeBSD 5.0 中发布时，被标记为实验性，具有以下几个含义
• 启用它需要重新编译内核。
• 文档将其标记为可能不完整、不稳定或不安全，因此不受支持。
• 编程和二进制接口（API、KPI、ABI 和 KBI）稳定性被声明为不保证，允许在没有正式弃用的情况下进行更改。
在框架仍处于实验阶段时合并它是获得可以帮助验证和改进该方法的用户的关键，同时保留进行更改的灵活性。在框架被认为是适合生产之前，需要解决两个问题
• 内核、策略和其他模块的二进制兼容性影响必须得到更好的理解。
• 必须根据社区审查分析和优化性能。
KPI 和 KBI 弹性
FreeBSD 策略规定，针对某个版本编译的某些类别的内核模块必须与同一系列中的后续次要版本一起工作（例如，FreeBSD 9.0 网络设备驱动程序应与 FreeBSD 9.1 一起工作）。目标是避免破坏消费者子系统的 KBI，并为策略模块提供类似的二进制兼容性级别。子系统和策略的标签存储不透明性是主要的改进领域，如果它们只需要标签访问，这可以避免将内核数据结构内部结构编码到策略中，并为更改标签实现提供灵活性。
性能优化
许多 FreeBSD 部署对性能非常敏感，需要最小的开销，尤其是在禁用框架的情况下。由于站点根据本地安全性能权衡选择策略，因此策略也希望只产生它们实际使用的功能的性能损失——性能比例性。然而，正如 FreeBSD 5.0 中发布的那样，回归是可测量的，这是默认启用框架的障碍。
标签分配权衡
即使在编译输出框架时，从向内核数据结构（尤其是数据包mbufs）添加标签造成的膨胀也会产生显着的分配时清零成本。在 FreeBSD 5.1 中，内联mbuf标签被指针替换，并且在 5.2 中对所有对象类型都进行了替换；这降低了非 MAC 内核的成本，但以 MAC 启用内核的额外分配和间接为代价。
启用框架后，标签分配甚至更可测量——并且对于未标记的策略是不必要的。这种影响在网络数据包中最为明显，并在 FreeBSD 5.1 中导致每个策略标志请求数据包标签。在 8.0 中，这种方法被推广，以便仅为至少一个已加载策略定义初始化入口点的对象类型分配标签。这有效地消除了策略不需要时的标签成本，恢复了性能比例性，并很好地满足了一般情况。然而，一个使用数据包标记的商业产品，McAfee Sidewinder 防火墙，看到了足够的开销以至于绕过标签抽象，转而直接修改结构。
最小化同步开销
在编译框架后，入口点调用上的锁保护引用计数操作对于频繁操作（例如，每个数据包传递检查）很容易测量。随着多核硬件变得越来越普遍，锁（以及后来的缓存行）争用也变得显着。
从 FreeBSD 5.2 开始，策略被分为静态和动态集，以帮助固定配置的嵌入式系统。前者在启动时编译或加载，并在之后不可卸载，因此不需要同步。动态策略——在启动后加载或可能卸载的策略——仍然需要多次锁定操作。
在 FreeBSD 8.0 中，进一步优化了同步，以便 MAC 框架可以默认包含在内核中。这项工作受益于内核可扩展性的持续改进，这得益于日益常见的八核机器的驱动。特别关键的是读多写少锁，它不会在只读获取期间触发缓存行迁移，但代价是更昂贵的独占获取——非常适合不经常更改的策略列表。
nCircle IP360 设备
nCircle Network Security 生产基于 FreeBSD 的设备 IP360，用于扫描网络中是否存在易受攻击的软件和 Sarbanes-Oxley 合规性。虽然其大多数安全要求可以通过传统的 DAC 捕获，但客户要求能够直接审核设备内容和配置。为了满足此要求，同时限制在审核访问被滥用或泄露情况下的潜在损害，nCircle 开发了一个自定义策略。
该策略授权审核用户读取所有文件系统和配置数据，绕过权限，同时还阻止文件系统写入。MAC 框架只能表达此增强功能的子集：策略可以约束权限，但不能授予权限。因此，nCircle 增强了框架，以允许控制细粒度的系统特权。
特权扩展
操作系统特权授予绕过操作系统安全策略的权利（例如，更改系统设置或覆盖 DAC 或进程模型）。在经典的 Unix 中，系统特权被授予以 root 用户身份运行的任何进程。为了满足 nCircle 的目标，策略必须能够增强内核的默认特权策略，以便为其他用户授予（和缓和）特权。这提出了两个技术挑战：如何识别和区分不同类型的特权，以及如何将可扩展性添加到现有的特权模型中。这些问题在微观层面上类似于 MAC 框架解决的更大问题——构建用于可扩展性的参考监视器——并且尽管偏离了最初仅限制而非授予权利的设计选择，但似乎也很自然。
分析了所有现有的内核特权检查，并将其替换为特定命名的特权的检查。然后，重新设计了特权检查，以包括特权来源和限制的显式组合策略，包括两个新的 MAC 框架入口点mac_priv_check遵循标准入口点约定，接受凭证和命名特权参数，并通过返回错误来限制特权；mac_priv_grant通过覆盖基本操作系统策略以授予新权利来背离此模型，使用新的组合运算符，该运算符允许任何策略授予权利，而不是要求所有策略都同意。
更新了现有策略以利用新功能，从而为 root 用户提供更强大的非自主控制。例如，Biba 策略现在限制对许多特权的访问，这些特权可能允许在以 root 用户身份操作但没有 Biba 特权时绕过进程模型或系统重新配置。这些功能在 FreeBSD 7.0 中发布。
nCircle MAC 策略
nCircle 策略扩展（和限制）了审核用户可用的权利
• 它标识了一个特定的用户 ID，所有剩余的策略活动都适用于该用户 ID。
• 授予了特权，包括对内核日志和防火墙配置的读取访问权限，并覆盖了文件读取/查找保护。
• VFS 入口点拒绝写入访问所有对象和读取访问某些文件（如密码文件）。
通过这些增强功能，nCircle 策略能够将受控的特权提升与强制性约束相结合，在满足产品需求的同时，最大限度地减少本地操作系统修改。
Juniper Junos
Junos 路由器操作系统在所有 Juniper 路由器和交换机的控制平面上运行。Juniper 维护对 FreeBSD 的大量本地修改，并且正在经历一个多年的过程，通过将改进返回给 FreeBSD 社区并增加操作系统可扩展性框架的使用来最大限度地减少其补丁，这些框架允许将本地功能干净地嫁接到未修改的操作系统上。作为该项目的一部分，Juniper 一直在将本地安全扩展迁移到 MAC 框架策略中，既可以减少 FreeBSD 更新期间的冲突，又可以为某些策略的上游化做准备。Junos 附带四个本地安全扩展
•mac_runasnonroot。确保针对 Junos SDK 编写的第三方应用程序不以 root 用户身份运行。
•mac_pcap。允许 Junos SDK 应用程序捕获数据包，即使不以 root 身份运行。
•mac_veriexec。实现对数字签名二进制文件的支持。
• Junos SDK 沙箱化。基于mac_veriexec证书
约束第三方应用程序。mac_runasnonroot和mac_pcap扩展首先在 2009 年作为框架策略发布。然后mac_veriexec在 2012 年发布，取代了以前直接修补的实现。Juniper 正在准备将 Junos SDK 沙箱化迁移到 MAC 框架，以进一步减少本地补丁，并上游化mac_veriexec.
这些策略需要对 MAC 框架进行少量更改，包括额外的入口点；也许最有趣的是新的O_VERIFY标志到open系统调用，它向框架发出信号，表明用户空间运行时链接器已请求验证文件。
Apple OS X 和 iOS
Apple 迅速发布了用于桌面/服务器的 OS X Leopard 版本（2007 年）和用于 iPhone 和 iPod Touch 的 iPhone OS 2（2008 年），将 MAC 框架作为参考监视器框架合并。OS X Snow Leopard 附带了三个 MAC 策略
• 沙箱。 提供策略驱动的风险组件沙箱化，这些组件处理不可信数据，例如网络服务和视频编解码器。
• 隔离。 污损下载的文件，支持显示来源网站的用户对话框。
• 时间机器安全网。 保护时间机器备份的完整性。
在 OS X Mountain Lion 中，通过 Apple App Store 分发的应用程序具有强制沙箱化。Apple 的 iOS 2.0 附带了两个策略：沙箱和一个额外的策略
• Apple 移动文件完整性 (AMFI)。与代码签名工具协同工作，终止在运行时数字签名无效的应用程序；在应用程序开发期间免除调试。
这些策略共同支持系统完整性，并在应用程序之间提供强大的隔离，以保持数据私密性。OS X 和 iOS 都大大背离了我们对 MAC 框架的设计预期，需要进行重大调整。
XNU 原型
Apple 于 2000 年开始测试 OS X Beta 版，而具有开源内核的商品桌面操作系统的前景令人难以忽视。XNU 内核是卡内基梅隆大学的 Mach 微内核、FreeBSD 5.0、精选的较新 FreeBSD 元素以及 Apple 开发的众多功能的复杂混合体。有了这些基础，MAC 框架方法，甚至代码，似乎都是可重用的。
虽然不是微内核，但 XNU（X is not Unix 的缩写）采用了 Mach 的许多元素，包括其调度程序、进程间通信 (IPC) 模型和 VM 系统。FreeBSD 进程模型、IPC、网络栈和 VFS 被嫁接到 Mach 上，提供了丰富的 Posix 编程模型。Apple 开发的 OS X 第一个版本中的内核组件包括 I/O Kit 设备驱动程序框架、网络内核扩展 (NKE) 和 HFS+ 文件系统；此列表随着时间的推移只会增长。
有趣的问题层出不穷：例如，在 DTMach16 和 DTOS17 微内核项目中开发的想法是否比 MAC 框架中的单内核方法应用得更好或更差？在 2003 年至 2007 年之间，日益成熟的 MAC 框架被移植到 OS X。18
适应 OS X
MAC 框架需要对 FreeBSD 内核进行详细分析，并且与低级内存管理和同步以及更高级别的服务（如文件系统、IPC 和网络栈）紧密集成。虽然适应 OS X 能够很大程度上依赖于 Apple 对 FreeBSD 组件的使用，但仍需要进行根本性的更改以反映 FreeBSD 和 XNU 之间的差异。
第一步是将 MAC 框架与紧密对齐的 BSD 进程模型、文件系统和网络栈集成。高层架构对齐使一些适配变得容易，但也遇到了重要的差异。例如，FreeBSD 的 Unix 文件系统 (UFS) 认为目录是专门的文件对象，而 HFS+ 认为目录和对象属性结构或磁盘目录是一流对象。这需要对框架和 XNU 进行更改。
接下来，覆盖范围扩展到包括 Mach 任务和 IPC。每个 XNU 进程都将 Mach 任务（调度、VM）与 FreeBSD 进程（凭证、文件描述符）链接起来，提出了一个哲学问题：MAC 框架是 Mach 的一部分还是 BSD 的一部分？虽然在架构上很有用，但 XNU 中的 Mach-BSD 边界被证明是人为的：引用经常跨越层，要求 MAC 框架同时为两者服务。对 BSD 进程标签的标签修改会镜像到相应的 Mach 任务标签。
Mach 端口是微内核起源与 MAC 框架的单内核前提发生冲突的另一个案例。与具有内核管理的命名空间的 BSD IPC 对象不同，Mach 端口依赖于由launchd（例如，用于桌面 IPC）管理的用户空间命名空间。借鉴 DTOS 的经验，launchd负责标记和强制执行，但查询参考监视器以授权查找。类似于内核label结构的用户空间标签句柄抽象服务于此目的。
Apple 的采用
苹果是全球最大的桌面 Unix 系统供应商，也是最早在智能手机中部署 Unix 的公司之一。随着无处不在的网络和恶意攻击者的出现，Unix 的应用场景和新的安全需求也呈爆炸式增长。然而，苹果公司采用 MAC 框架并非一蹴而就，因为当时也考虑了其他竞争技术，这些技术的推动因素包括类似的观察、对未来产品方向的认识、性能方面的担忧以及我们的研究。
备选方案包括类似于前面讨论的基于系统调用拦截的技术，以及苹果公司的 Kauth3（内核授权的缩写），这是一种面向防病毒厂商的授权框架（部分以 MAC 框架为模型）。苹果公司认为关于系统调用拦截的不可靠性的论点令人信服，最终采用了两种技术：Kauth 用于第三方防病毒厂商，而更具表现力和功能的 MAC 框架用于其自身的沙盒技术。
沙盒策略
由于苹果公司的 OS X 和 iOS 策略模块不是开源的，我们无法研究它们的具体实现，但是 Mac OS X 组件和第三方应用程序（如 Google Chrome 浏览器）使用的沙盒策略有公开文档。沙盒允许应用程序自愿限制其对资源的访问（例如，文件系统、IPC 命名空间和网络）。进程沙盒配置文件存储在进程标签中。
字节码编译的策略可以通过公共 API 或以下方式设置：sandbox-exec辅助程序。应用程序可以从几个苹果定义的策略（表 2）中选择，也可以定义自定义策略。一些应用程序使用默认策略，例如 iChat 视频编解码器，它采用仅限于与宿主进程进行 IPC 的 computation-only 配置文件。表 3 列出了其他几个使用自定义配置文件的 OS X 程序。
图 9 显示了以下内容的摘录：common.sbChrome 使用的配置文件，展示了关键的沙盒构造：针对以下内容的粗粒度控制：sysctl内核管理接口和共享内存，以及对文件路径进行细粒度的正则表达式匹配。基于文件路径的控制是沙盒策略的一个亮点，它比 Biba、MLS 和 TE 中的文件标签更好地解决了程序员模型的问题。基于路径的方案在 Unix VFS 模型上难以实现，因为该模型将路径视为二等公民。虽然 FreeBSD 允许文件拥有零个（已取消链接但已打开）、一个或多个名称（硬链接），但 HFS+ 为文件实现了父指针，并确保名称缓存始终包含计算正在使用文件的明确路径所需的信息。
虽然沙盒被用于许多 OS X 服务，但许多第三方应用程序都包含对环境权限的强烈假设，即访问系统中任何对象的能力。在 iPhone 上，苹果打破了这个假设：应用程序彼此隔离且与系统服务隔离地执行。这种模型现在正出现在 OS X 中，并且同样可以帮助保护设备完整性，防止行为不端的应用程序，以及越来越多的终端用户数据。
性能优化
OS X 和 iOS 在 FreeBSD 8.0 的性能优化之前就已搭载了 MAC 框架，这要求苹果公司根据产品特定的约束进行自己的优化。与 FreeBSD 优化一样，这些优化通常与框架入口和标签的开销有关。默认情况下，对于某些对象类型，标签编译在内核之外；对于其他对象类型，例如vnodes，策略可以有选择地请求标签分配，以适应 OS X 策略中标签的通常稀疏使用情况。
在 FreeBSD 中，框架检测和同步优化依赖于站点之间愿意为额外的访问控制扩展付费的非此即彼的区别。在 OS X 中，假设沙盒技术在大多数机器上使用，但有选择地应用于高风险进程。为此，每个进程都携带一个由策略设置的掩码，指示哪些对象类型需要强制执行。随着 OS X 采用更通用的沙盒技术（就像 iOS 中的情况一样），可能需要应用更全局的优化，就像在 FreeBSD 中一样。
反思
在过去的十年中，MAC 框架已成为许多安全本地化实例的基础，允许将本地访问控制策略与仍然流行的 Unix 自主访问控制 (DAC) 模型相结合——这是行业需求和研究的及时融合。通过开源进行部署被证明是一个成功的策略，为协作改进、早期采用者访问以及通往众多产品的道路提供了论坛。
也许最令人惊讶的采用是在 McAfee 本身：当 McAfee Research 开源该框架时，Secure Computing Corporation（当时是竞争对手）为 Sidewinder 采用了它，McAfee 后来收购了 Secure Computing Corporation。更广泛地说，这说明了开源在提供一个场所方面的成功，在这个场所中，竞争公司可以合作开发通用基础设施技术。我们的访问控制可扩展性论点很好地满足了行业对设备和嵌入式设备开源基础的采用
• 设备中的安全本地化已变得普遍。
• 多处理的关键性只会增加。
• 安全标签抽象已被证明在其 MAC 根源之外是有益的。
• 关于访问控制策略的非共识仍在继续。
然而，MAC 框架也需要改进和扩展，以解决几个未预料到的问题
• 重新审视 Unix 权限结构的愿望。
• 在将访问控制应用于第三方应用程序时，数字签名的重要性。
• 在基于名称与基于标签的访问控制的愿望上持续存在紧张关系。
新的设计原则
鉴于 MAC 框架的广泛现场经验，我们添加了几个新的设计原则
策略作者决定他们自己的性能、功能和保证权衡。策略可能不需要重量级基础设施（例如，标签），因此提供性能比例性。
可追溯性是关键的设计考虑因素。
编程和二进制接口稳定性至关重要。API、ABI、KPI 和 KBI 的可持续性在研究中经常被忽视，在研究中，原型通常是一次性的，没有数十年的支持义务。
操作操作系统权限对于增强而非补充 DAC 的策略非常重要.
然而，从下游消费者的工作中可以清楚地看出，现在还需要两个进一步的原则
应用程序作者是一等公民。苹果公司的 App Store 和 Juniper 的 SDK 都使用应用程序签名和证书作为策略输入。
应用程序本身需要灵活的访问控制来支持应用程序隔离。
后一个观察结果促使我们开发了以应用程序为中心的 Capsicum 保护模型21，该模型最近已作为 FreeBSD 9.0 中的实验性功能发布。它可以被视为对策略驱动的内核访问控制的补充。
领域特定的策略模型
为什么在操作系统策略的表达方面没有达成共识是一个有趣的问题——当然，连续策略模型的支持者认为他们的模型抓住了系统设计的关键问题。为了满足各种模型，我们的观察是双重的：首先，策略模型旨在捕捉最小特权原则15的各个方面，但通常以根本不同的形式（例如，信息流与系统特权），使其方法具有互补性；其次，不同的模型在表达类型、保证、性能、管理复杂性、实现复杂性、兼容性和可维护性之间的多维权衡中解决了不同的空间。这反而反映了对领域特定的策略模型的共识。
可扩展性的价值
对重大设计改进的需求是证实还是否定了访问控制可扩展性的假设？进一步与类似的框架（例如 VFS 和设备驱动程序）进行比较似乎是合适的：两者都定期扩展以适应新的需求，例如分布式文件系统技术的变化或电源管理的改进。工业消费者扩展框架并返回改进的意愿反映了我们关于可扩展性的根本经济学假设：管理重要源代码库的上游-下游关系是一个强大的推动力。MAC 框架的广泛而持续的部署似乎证实了更普遍的论点，即访问控制可扩展性是当代操作系统设计的关键方面。
致谢
系统研究强调将思想应用于真实世界的系统：只有通过实现一个想法，你才能充分理解它；从研究到实践的过渡更是如此。框架贡献的致谢应归功于众多机构的庞大阵容，包括 Samy Al Bahra、John Baldwin、Simon Cooper、Hrishikesh Dandekar、Rob Dekelbaum、Brian Feldman、Mark Feldman、Tim Fraser、Shawn Geddis、Ilmar Habibulin、Mike Halderman、Doug Kilpatrick、Suresh Krishnaswamy、Terry Lambert、Scott Long、Pete Loscocco、Jim Magee、Adam Migus、Todd Miller、Wayne Morrison、Christian Peron、Andrew Reisse、Wayne Salamon、Mike Smith、Stacey Son、Tom Van Vleck、Chris Vance 和 Zhouyi Zhou。
Richard Gaushell、Simon Gerraty、Matthew Grosvenor、Steve Hand、Steve Kiernan、Anil Madhavapeddy、George Neville-Neil 和 Mike Silbersack 对本文提出了有益的反馈。特别感谢 Ross Anderson、Lee Badger、Jon Crowcroft、Mark Handley、Ben Laurie、Doug Maughan 和 Peter G. Neumann 在整个过程中的支持。
多家公司为 MAC 框架做出了贡献，包括 Apple、Google、Intel、Juniper、McAfee、nCircle、Seccuris 和 SPARTA。这项工作得到了国防高级研究计划局/空军研究实验室 (DARPA/AFRL) 合同 FA8750-10-C-0237 (CTSRD) 的支持，之前的支持来自 DARPA CBOSS 和 SPAWAR SEFOS 合同，共同跨越 DARPA CHATS 和 DARPA CRASH 研究计划。本文中包含的观点、意见和/或发现是作者的观点，不应被解释为代表 DARPA、美国海军、AFRL 或国防部的明示或暗示的官方观点或政策。
参考文献
1. Abrams, M. D., Eggers, K. W., LaPadula, L. J., Olson, I. M. 1990. 通用访问控制框架：非正式描述。载于第 13 届 NIST-NCSC 国家计算机安全会议论文集：135-143。
2. Anderson, J. P. 1972. 计算机安全技术规划研究。技术报告，电子系统部，空军系统司令部。
3. Apple Inc. 2007. 内核授权。技术说明 TN2127； http://developer.apple.com/technotes/tn2005/tn2127.html。
4. Badger, L., Sterne, D. F., Sherman, D. L., Walker, K. M., Haghighat, S. A. 1995. Unix 的实用域和类型强制。载于1995 年 IEEE 安全与隐私研讨会论文集：66。IEEE 计算机协会。
5. Bell, D. E., 和 L. J. LaPadula。1973. 安全计算机系统：数学基础和模型。技术报告 M74-244。Mitre Corp., Bedford, MA。
6. Biba, K. 1977. 安全计算机系统的完整性考虑因素。技术报告 TR-3153。Mitre Corp., Bedford, MA。
7. Boebert, W. E., Kain, R. Y. 1985. 分层完整性策略的实用替代方案。载于第 8 届国家计算机安全会议论文集。
8. Cantrill, B. M., Shapiro, M. W., Leventhal, A. H. 2004. 生产系统的动态检测。载于Usenix 年度技术会议论文集，伯克利，加利福尼亚州。Usenix 协会。
9. Fraser, T., Badger, L., Feldman, M. 1999. 使用通用软件包装器加固 COTS 软件。载于1999 年 IEEE 安全与隐私研讨会论文集。
10. Kleiman, S. R. 1986. Vnodes：Sun Unix 中多种文件系统类型的架构。载于1986 年夏季 Usenix 会议论文集。
11. Loscocco, P. A., Smalley, S. D. 2001. 将安全策略的灵活支持集成到 Linux 操作系统中。载于Usenix 年度技术会议论文集： 29-42。Usenix 协会。
12. McKusick, M. K., Neville-Neil, G. V. 2004. FreeBSD 操作系统设计与实现。 Pearson 教育。
13. Neumann, P. G., Boyer, R. S., Feiertag, R. J., Levitt, K. N., Robinson, L. 1980. 可证明安全的操作系统：系统、其应用和证明，第二版。技术报告 CSL-116。计算机科学实验室，SRI 国际。
14. Ott, A. 2010. Linux 的基于规则集的访问控制 (RSBAC)； http://www.rsbac.org/。
15. Saltzer, J. H., Schroeder, M. D. 1975. 计算机系统中信息的保护。载于IEEE 论文集 63(9): 1278-1308。
16. Sebes, E. J. 1991. 分布式可信 Mach 架构概述。载于Usenix Mach 研讨会论文集：20-22。Usenix 协会。
17. Spencer, R., Smalley, S., Loscocco, P., Hibler, M., Andersen, D., Lepreau, J. 1999. Flask 安全架构：对各种安全策略的系统支持。载于第 8 届 Usenix 安全研讨会论文集：123-139。Usenix 协会。
18. Vance, C., Miller, T. C., Dekelbaum, R., Reisse, A. 2007. 安全增强型 Darwin：将 SELinux 移植到 Mac OS X。载于第三届年度安全增强型 Linux 研讨会论文集。
19. Watson, R. N. M. 利用系统调用包装器中的并发漏洞。载于第一届 Usenix 进攻性技术研讨会论文集：1-8。(2009) Usenix 协会。
20. Watson, R. N. M. 2012. 操作系统安全可扩展性的新方法。技术报告 UCAM-CL-TR-818。剑桥大学计算机实验室。
21. Watson, R. N. M., Anderson, J., Laurie, B., Kennaway, K. 2010. Capsicum：Unix 的实用功能。载于第 19 届 Usenix 安全研讨会论文集。Usenix 协会。
22. Watson, R. N. M. Feldman, B., Migus, A., Vance, C. 2003. TrustedBSD MAC 框架的设计与实现。载于第三届 DARPA 信息生存能力会议和展览论文集 (DISCEX)。IEEE。
23. Wright, C., Cowan, C., Morris, J., Smalley, S., Kroah-Hartman, G. 2002. Linux 安全模块：Linux 内核的通用安全支持。载于第 11 届 Usenix 安全研讨会论文集。Usenix 协会。
喜欢还是讨厌？请告诉我们
ROBERT N. M. WATSON 博士是剑桥大学计算机实验室的高级研究助理，也是剑桥圣约翰学院的研究员，他的研究兴趣包括操作系统安全和网络、硬件-软件接口以及程序分析和转换。在剑桥大学获得博士学位之前，Watson 博士曾担任 SPARTA ISSO 的高级首席科学家和 McAfee Research 的高级研究科学家。他在那里的工作包括领导为开源 FreeBSD 操作系统开发内核访问控制扩展框架，该框架现在用于从 McAfee Sidewinder 和 Juniper Junos 到 Apple OS X 和 iOS 的各种产品中。Watson 博士是 FreeBSD 项目的常客；这已是他担任非营利组织 FreeBSD 基金会董事会成员的第十年。
© 2012 1542-7730/11/1200 $10.00
最初发表于 Queue vol. 11, no. 1—
在 数字图书馆 中评论本文
更多相关文章
Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用机密联邦学习的可信 AI
安全性、隐私性、问责制、透明度和公平性原则是现代 AI 法规的基石。经典的 FL 在设计时非常强调安全性和隐私性，但以透明度和问责制为代价。CFL 通过将 FL 与 TEE 和承诺相结合，弥补了这一差距。此外，CFL 还带来了其他理想的安全属性，例如基于代码的访问控制、模型机密性以及推理期间的模型保护。机密计算（如机密容器和机密 GPU）的最新进展意味着可以无缝扩展现有的 FL 框架，以低开销支持 CFL。
Raluca Ada Popa - 机密计算还是密码计算？
通过 MPC/同态加密与硬件飞地进行安全计算，在部署、安全性和性能方面存在权衡。关于性能，您心中考虑的工作负载非常重要。对于简单的求和、低次多项式或简单的机器学习任务等简单工作负载，这两种方法都可以在实践中使用，但对于复杂的计算（如复杂的 SQL 分析或训练大型机器学习模型），目前只有硬件飞地方法在许多实际部署场景中足够实用。
Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 机密容器组
此处介绍的实验表明，Parma（在 Azure 容器实例上驱动机密容器的架构）增加的额外性能开销不到底层 TEE 增加的开销的百分之一。重要的是，Parma 确保容器组所有可达状态的安全不变性，根植于证明报告。这允许外部第三方与容器安全地通信，从而实现各种需要机密访问安全数据的容器化工作流程。公司获得了在云中运行最机密工作流程的优势，而无需在其安全要求上妥协。
Charles Garcia-Tobin, Mark Knight - 使用 Arm CCA 提升安全性
机密计算通过将监管系统从 TCB 中移除，从而减小 TCB 的大小、攻击面和安全架构师必须考虑的攻击向量，从而在提高通用计算平台的安全性方面具有巨大的潜力。机密计算需要平台硬件和软件方面的创新，但这些创新有可能增强对计算的信任，尤其是在由第三方拥有或控制的设备上。机密计算的早期消费者将需要自行决定他们选择信任的平台。
© 保留所有权利。