深入潜入MacOS 11的内部，揭示了一些安全惊喜，应该得到更广泛的知名度。

内容

  1. 介绍
    1. 免责声明
  2. macOS 11更广为人知的安全改进
    1. 秘密信息披露?
  3. CPU安全降低api
    1. 的NO_SMT缓解
    2. 的侦探缓解
    3. 谁从中受益NO_SMT和侦探？
  4. 端点安全API改进
    1. 更多的消息类型
    2. 更多通知，更少轮询
    3. 更多元数据
    4. 提升的性能
  5. 一个悄然固定的漏洞
  6. O_NOFOLLOW_ANY
  7. 结论
  8. 尾注

介绍

当一个操作系统的新版本发布时，普通人通过参加开发人员会议、阅读版本说明、更新日志和评论来发现新版本。

我，我下载了新版本的软件开发套件（SDK），并使用当前版本差异。

这在Windows上并不少见:有专门从事大规模、长期、差异化逆向工程的整个网站，告诉你在哪个版本的Windows中出现了什么新功能，它们与其他功能的关系如何变化，内部数据结构如何演变等等。在macOS上，似乎没有人这样做(至少在公开场合没有)，一些简单的事情，比如从一个SDK版本到下一个SDK版本，将包含的内容进行区分，然后耐心地逐个文件地查看，可能会揭示出没人知道(或至少谈论过)的有趣特性。

比较macOS 11和macOS 10.15 sdk，我发现了几个值得更广泛了解的有趣惊喜。

免责声明

在本文中，我将描述一些文档记录很差或完全没有文档记录的特性，这些特性可能会像宣传的那样停止工作，或者在macOS的未来版本中完全消失。运用常识，评估风险，做出选择，并为你的选择承担责任。

请注意，我只是一个开发人员，既不是安全研究员也不是漏洞利用作者，以及我对安全问题的描述和他们的缓解可能会陷入“略微不正确”和“完全错误”之间。我欢迎更正。

macOS 11更广为人知的安全改进

在WWDC 2020，Apple致敬了几个新的麦克斯和iOS特征，实际上是大问题。这篇文章应该早些时候出来，我不希望任何人仍会记住一年多的大惊小怪，所以我会给你一个简短的回顾。

将在MacOS 11中首次亮相的主要新安全功能是：

  • 指针认证码(PAC)，由Apple本土64位ARM处理器，M1实现的硬件强制呼叫流程（CFI）。目前仅限于系统代码和内核扩展，但为所有第三方开发人员开放进行实验。
  • 设备隔离是另一个M1的功能，它使用该平台的更强大的Iommu来确保硬件设备只能与操作系统共享内存，而不是相互共享。跨设备内存共享是一种历史自定义，基于盲人，对硬件的盲目信任。
  • 写入XOR执行(W^X)最终以硬件强制的形式出现在macOS上(是的，这是另一个m1独有的特性)。内存页现在可以是可写的，也可以是可执行的，但不能同时是两者;没有例外。JIT (Just-in-time)编译器需要围绕这一限制进行重新设计，才能在ARM mac上运行，但是特殊的api是为了使工作更容易。
  • 签名系统卷（SSV）以加密方式密封了引导卷，使其不受篡改。(MacOS从10.15开始从只读卷启动。)苹果的多层保护数据文章简要描述了SSV，但霍华德奥克利有一个偶在他的博客上更详细地写作,插图;一个不可不读。你还应该看看安德鲁·坎宁安的macos11的回顾．

这些技术刚刚赢得了新闻和安全研究人员的注意，他们在其他地方的详细讨论过。（Apple视频探索苹果硅mac电脑的新系统架构WWDC 2020的10686部分对大多数新安全特性有一个很好的概述，等等。)

关于这些话题，我真的没有什么可以补充的，但还有其他的安全改进，似乎每个人都错过了，而苹果似乎羞于提及。

秘密信息披露?

转念一想，也许是我的翻找方法罐头添加一些小说（虽然令人难以置信的琐碎）到公开披露的安全改进：我没有看到任何人提到的事实是，加密密封的文件系统底层SSV是内部代码的“Cryptex”。的中的(5)手册上说:“cryptex这个名字是‘cryptographicically -sealed EXtension’的合成词。”

但我知道，我们知道，他们知道他们的名字取自丹·布朗最畅销的获奖鸟笼班轮达芬奇密码．否则忘记（和最遗忘的）机场惊悚片引入了一个有趣的概念cry:密信，用密码锁密封，如果用武力打开就会自毁。

这里有一些有趣的暗示中的(5)暗示着一个更广阔的密码箱电影宇宙，比如引用cryptexctl (1)命令和一个cryptexd (8)守护进程，但这些人的页面无处可供找到，也不是麦斯科斯的两个二进制部分。一个占位符的人页libcryptex (3)除了一个有趣的细节之外，除了一个有趣的细节之外，除了一个有趣的细节之外，没有任何意见：2018年10月19日的版权日期，这表明SSV已经发展了一个长在最终用户特性具体化之前的时间。

SDK包含导入库libcryptex，libcryptex_core和libcryptex_interface.，但没有库本身，所以我们有导出的符号列表，但没有它们背后的代码。这些库也不是macOS的一部分，这让我认为，在SDK中发现的分散的Cryptex文物可能从苹果的私人代码栏中逃了出来，但不知道是如何逃出来的。

符号列表所能告诉我们的是，政治上正确的“密码学密封扩展”修正主义可以被终结了:对我来说，函数的名字像codex_install_pack(出口libcryptex_interface.）毫无疑问地证明了一个名字的布朗起源！

CPU安全降低api

开发人员被教导认为CPU是一个完美的数学抽象。2018年微架构漏洞之年(幽灵和崩溃我们的观点是:cpu运行于代码中;CPU开发人员无法在没有竞争条件的情况下编写多线程代码;他们制造的cpu漏洞百出，不可靠，而且是叛国的，它们与反对操作系统(OS)的应用程序合谋，以无法察觉的方式绕过访问控制。

可以修复的问题被修复了。剩下的问题只能以性能为代价，在操作系统或编译器中得到缓解。我知道微软在Windows更新时推出的缓解措施，新的MSVC编译器选项/ qspectre.，对Chrome JIT编译器的更改，以防止它从恶意JavaScript等生成可利用代码等。

但是，我惊讶地发现了macOS 11中新的、未宣布的、完全没有记录的缓解。

据我所知，这是第一篇描述它们的公开文章。新的api几乎没有返回任何命中grep.app.或github代码搜索 - 或谷歌就那件事而言。

提供了两种代号为的缓解措施NO_SMT和侦探．让我们仔细看看他们。

的NO_SMT缓解

它是什么？

NO_SMT禁用同时多线程（SMT），CPU在英特尔的“超线程”的商品名下更好地知道。SMT允许CPU核心同时执行两个或更多线程，以提高性能，以获得每核资源的争用成本，例如缓存，TLB等。

让多个线程共享不可见资源会带来风险，即让恶意线程从运行在同一核心上的“兄弟”线程窃取秘密——多年来，这种风险已经变成了多种攻击，如TLBleed、PortSmash、Fallout、zombiload、RIDL。对于过去和未来的整个系列攻击，一个简单的缓解方法是禁用SMTNO_SMT所做的事。

如何使用NO_SMT

在C / c++中,# include < libproc.h >；不需要额外的图书馆。从：

/* * NO_SMT意味着在SMT CPU上，这个线程必须单独调度，*与成对的CPU空闲。* * Set NO_SMT on the current proc (all existing and future threads) * This attribute is inherited on fork and exec */ int proc_set_no_smt(void) __API_AVAILABLE(macos(11.0));/*在当前线程上设置NO_SMT */ int proc_setthread_no_smt(void) __API_AVAILABLE(macos(11.0));

简单的电话proc_set_no_smt.启用NO_SMT对于整个进程(现有的和未来的线程一样)，或者proc_setthread_no_smt.仅为调用线程启用它。就像评论说的，叉（2）子进程继承父进程的NO_SMT状态,exec（2）不会重置。

请注意,“libproc是一种用词不当的说法，而且这些不是库函数，而是私有系统调用上的瘦C包装器process_policy (2)．

NO_SMT也扩展了posix_spawn (2)，这样我们就可以为新进程启用缓解，而不需要为当前进程设置它们，也不需要生成短期的叉（2）孩子（理想情况下，我们应该永远不要打电话叉（2）再一次在任何新代码中，在任何操作系统中。过)。从< spawn.h >：

int posix_spawnattr_setnosmt_np(const posix_spawnattr_t * __restrict attr) __API_AVAILABLE(macos(11.0));

posix_spawnattr_setnosmt_np (3)执行相当于proc_set_no_smt.在新的过程中。在函数名中，“_np”后缀表示“不可移植的”:标记os特定扩展的习惯方法posix_spawn (2)．

“但我已经使用了叉（2）我无法停止使用它！如何启用NO_SMT后exec（2）没有为fork子结点启用它们?”你很幸运，因为macOS已经覆盖了你:任何posix_spawn (2)功能自动可用exec（2）多亏了非标准国旗POSIX_SPAWN_SETEXEC，可以设置为posix_spawnattr_t使用posix_spawnattr_setflags (3),使posix_spawn (2)表现得exec（2），替换当前流程而不是创建新的流程。

它是如何工作的?

NO_SMT实现为每个任务(不是每个进程［1］)国旗,名叫TF_NO_SMT或命名的每个线程调度标志TH_SFLAG_NO_SMT．标志从任务复制到它们的子任务、任务和线程;它是写一次标志，一旦设置就不能删除。然后将标记从每个线程复制到它们当前运行的CPU(字段)processor_t :: clust_is_no_smt.)．

NO_SMT由dualq调度算法，以一种非常直接的方式NO_SMT线程不能与其他线程共享CPU内核。

NO_SMT是否可以使用boot参数在系统范围内禁用disable_NO_SMT_threads，这将导致内核变量sched_allow_no_smt_threads.初始化0而不是1．目前的价值sched_allow_no_smt_threads.可以用sysctl查询kern.sched_allow_no_smt_threads.：

tstudent @ mac-67c2fa8ca4ec〜％sysctl kern.sched_allow_no_smt_threads kern.sched_allow_no_smt_threads：1

相当于NO_SMT通过设置NVRAM变量，可以在固件级别系统宽SMTDisable来％01.，如上所述Apple支持文章HT210108．

为什么你可能不应该使用NO_SMT

启用NO_SMT通过API，而不是配置固件以在禁用SMT支持的情况下启动计算机，而是提供有限的保护，如sched_allow_no_smt_threads.变量在运行时可以被超级用户写:

tstudent@MAC-67C2FA8CA4EC ~ % sudo sysctl kern。sched_allow_NO_SMT_threads = 0密码:尘粒。sched_allow_NO_SMT_threads: 1→0

这瞬间禁用NO_SMT系统级的。我想知道他们为什么要把它设置为“只写一次”标志，只让它变得如此容易禁用。

的侦探缓解

它是什么？

我一直不知道是什么侦探代表。我能得到的最接近的注释来自内核的源代码(osfmk / kern / task.h，来自XNU 7195.50.7.100.1):

#define TF_TECS 0x00020000 /*任务线程必须启用CPU安全*/

ThreadE尼布尔C聚氨酯年代安全吗?即使这是正确的解释，也不能帮助我们理解它的作用。

在它的当前版本中(通用名称暗示了未来细节可能会改变)，侦探在从内核模式返回到用户模式之前，刷新某些内部CPU缓冲区。这是对非法数据缓存加载(RDCL)系列攻击(如崩溃）和微体系结构数据采样（MDS）攻击系列（如ridl.和影响)．

如何使用侦探

不像NO_SMT，侦探没有专用的API，但它是通过一个称为CPU安全缓解(CPU Security mitigation, CSM)的通用API启用的，该API也可以启用NO_SMT．在C / c++中,# include < libproc.h >；不需要额外的图书馆。从：

/ * * CPU安全缓解API * *设置当前过程的CPU安全缓解（所有现有和未来的线程）*此属性在Fork和Exec * / Int Proc_set_csm（UInt32_t标志）__api_available（MacOS（11.0））上继承;/ *在当前线程* / int proc_setthread_csm（uint32_t flags）__api_available（macoS（11.0））上设置CPU安全缓解;/ * *用于CPU安全缓解API * PROC_CSM_ALL在大多数情况下，*单个标志仅用于性能评估等）* / #define proc_csm_all 0x0001 / *设置所有可用的缓解* / #define proc_csm_nosmt 0x0002 / * setno_smt  - 见上面* / #define proc_csm_tecs 0x0004 / *在每次返回到用户模式时执行verw * /

就像献身的NO_SMTAPI，我们可以使用整个当前过程的缓解proc_set_csm，或者只是调用线程proc_setthread_csm．CSM函数也是用于process_policy (2)．

最后,就像NO_SMT， CSM也可以扩展posix_spawn (2)．从< spawn.h >：

/* * Set CPU Security Mitigation on the派生进程*该属性影响所有线程，并在fork和exec上继承*/ int posix_spawnattr_set_csm_np(const posix_spawnattr_t * __restrict attr, uint32_t flags) __API_AVAILABLE(macos(11.0));#define POSIX_SPAWN_NP_CSM_ALL 0x0001 #define POSIX_SPAWN_NP_CSM_NOSMT 0x0002 #define POSIX_SPAWN_NP_CSM_TECS 0x0004 #define POSIX_SPAWN_NP_CSM_NOSMT 0x0002 #define POSIX_SPAWN_NP_CSM_TECS 0x0004

标志的含义与类似的命名相同国旗,posix_spawnattr_set_csm_np (attr POSIX_SPAWN_NP_CSM_NOSMT)是100%相同和可互换的吗posix_spawnattr_setnosmt_np (attr)．

它是如何工作的?

就像NO_SMT，侦探是一个write-once, enable-only标志，从任务复制到任务，从任务复制到线程，从线程复制到CPU。任务标志为TF_TECS．在任务级别以下，标志变成特定于体系结构的、仅适用于x86-64的标志，演变为代号为的缓解SEGCHK．因此，线程标志是布尔字段machine_thread: mthr_do_segchk， CPU标志为布尔字段cpu_data :: cpu_curthread_do_segchk.，亦称CPU_NEED_SEGCHK在汇编代码。

SEGCHK在内核到用户返回例程中完全实现汇编程序ks_64bit_return和ks_32bit_return．如果CPU_NEED_SEGCHK是为当前CPU设置的，它们执行一个VERW期末考试前不久的指导SYSEXIT/SYSRET/钉．VERW是一个模糊的和很大程度上过时的指令，检查指定的段(用户模式堆栈段，在情况SEGCHK）是可写的;但更重要的是，它具有冲洗RDCL和MDS攻击家庭利用的缓存的副作用，减轻了它们。

侦探只有在CPU支持的情况下才启用，或者默认情况下强制启用。CPU的支持侦探只检查x86-64，对应的是whetherSEGCHK是支持的。在启动时执行的检查是:

使用VERW作为一种缓解最初的建议由ridl的两个发现者（页200），但似乎它被证明不足，CPU供应商必须加强指示作为适当的缓解。摩托斯不相信未加强的VERW．

SEGCHK可以使用引导参数在系统范围强制执行。再一次,请参阅支持文章HT210108．同样，它可以通过无证的引导参数来强制关闭系统范围CWAD.（C聚氨酯W.工作一个rounddisable），它具有相同的语法CWAE.（C聚氨酯W.工作一个rounde威胁）。CWAE.优先CWAD.．

不像NO_SMT，SEGCHK/侦探没有等效的固件级别，也不能在引导后禁用。

谁从中受益NO_SMT和侦探？

谷歌。

我找遍了所有地方，似乎没有人在使用这些缓解api。唯一匹配的源代码(macOS 11和12 sdk之外，以及XNU源代码本身)是Chromium。我的macOS 11机器上唯一匹配的二进制文件(除了系统库)是Chrome和Electron框架，即Chromium。就连Safari浏览器似乎也不使用它们!

在Chromium中，当编译macOS时，基地:LaunchOptions结构传递给功能基地:LaunchProcess包含一个名为的布尔字段enable_cpu_security_mitigations；的macOS实现基地:LaunchProcess启动带有CSM标志的新流程posix_spawn_np_csm_all.．如果我对代码的理解正确，渲染器和插件宿主子进程启用了缓解，而对所有其他类型的子进程禁用了缓解(对代码的另一种解读表明，该功能已经实现，但未使用。老实说，我还没有挖得太深)。

很难想知道为什么Apple经历了实施缓解并将它们暴露为API，然后既不是文件也不是使用他们。如果它们是无效的，那么问题就变成了为什么谷歌要费劲地使用它们。不管怎样，我们都没有明确的答案。

端点安全API改进

对于本文的读者来说，端点安全性可能不需要介绍，但我还是要简要介绍一下。

这个CAPI，首先在MacOS 10.15中引入，替换和制作过时了预先存在的Archaic审计，监控和警务API（其中OpenBSM，Kauth，SocketFilter和尊重）acct (2)表示“最”。1979［2］)．

终端安全的设计结合了对MAC系统状态的近乎绝对的可见性和否决权［3.］策略模块具有客户端-服务器模型的安全属性，并在其之上有一个非常好的、文档非常详细的API。简而言之，它是各种安全应用程序的完美API。

还是吗?不幸的是，端点安全并非没有自己的缺点，但它们正在逐渐得到纠正。让我们看看macOS 11和12对端点安全做出的最重要的改进，其中只有一些是正式记录的。

更多的消息类型

现在可以检测更多的操作和/或否决，例如fcntl (2)，searchfs（2），Ptrace（2），重新安装文件系统，IOServiceOpen，task_name_for_pid，暂停进程和恢复进程。

有趣的是，进程挂起包括私有系统调用pid_shutdown_sockets，它实际上并不挂起进程，而是在它们已经挂起之后才关闭它们的网络连接。系统调用最初只在iOS上可用，在那里它是应用程序发送到后台的一部分。

macOS 12增加了更多的通知:setuid (2)，setgid（2），seteuid (2)，setegid (2)，setreuid (2)和setregid (2)．

更多通知，更少轮询

一些流程元数据过去只用于查询，需要轮询和/或差异来检测更改，现在生成更改事件。

ES_EVENT_TYPE_NOTIFY_CS_INVALIDATED消息会通知进程的代码签名已经无效(例如:CS_VALID标志不再设置)，但允许进程继续运行(即。CS_HARD标志没有设置)。以前，它只能通过私有系统调用进行轮询csops或csops_audittoken与操作码cs_ops_status.．

ES_EVENT_TYPE_NOTIFY_REMOTE_THREAD_CREATE消息通知远程(即进程间)线程的创建。在此之前，这些信息只能在低保真度下获得，并且需要付出很大的努力，通过轮询和不同Mach任务方法返回的数据task_info用味道TASK_EXTMOD_INFO，或通过监控syslogcom.apple.kernel.external_modification消息。

更多元数据

exec（2）消息现在包括新进程的工作目录（慢性消耗病es_event_exec_t::字段)。

现在所有消息的过程元数据包括：

  • 该过程的控制终端，如果有的话（es_process_t:遥控字段)。
  • 该过程的“开始时间”，即其进程标识符分配的时间叉（2）（es_process_t :: start_time.字段)。以前只能通过sysctl (2)与kern.proc.pid。<进程标识符>oid。
  • “负责任程序”(es_process_t :: coloudention_audit_token.例如，臭名昭著的“透明、同意和控制”(TCC)框架将用户同意的操作归咎于此。通常，这是导致启动守护进程/代理进程的客户端进程，在审计上下文中应该将其视为进程的“真正”父进程(而不是“占位符”)。xpcproxy (8))．以前仅可通过MAC策略模块的私有和完全没有文档记录的"责任" API进行隔离(例如:working_get_responsible_for_pid.)．

最后，有史以来第一次在麦克斯审计API中，现在报告的所有消息都不仅仅是导致要生成邮件的过程，而是确切的线程（es_message_t :: thread.字段)。

提升的性能

现在可以异步地处理消息，而不需要es_copy_message/es_free_message(相当于一个序列malloc，memcpy和免费的):消息现在被引用计数(参见新函数es_retain_message./es_release_message)，并且几乎可以免费地跨线程移动。es_copy_message和es_free_message已被彻底弃用，不应该再使用，除非是为了向后兼容macOS 10.15。它们不会被我或我的纺锤痕迹所错过。

一个悄然固定的漏洞

有时，不同的SDK版本甚至会暴露出被悄悄修复的安全漏洞。情况就是这样fcntl (2)命令F_SETSIZE．

F_SETSIZE用于更改分配给文件的最大磁盘空间:如果小于当前大小，文件将被截断;如果它更大，则扩展文件。是什么阻止恶意进程扩展文件以填满整个磁盘，然后从扩展文件中读取已删除的文件，将之前可用的空间分割出去?非常简单:F_SETSIZE用所有零填充新的文件空间，以隐藏它过去所包含的内容。作为一种优化，允许超级用户进程(有效用户id为0)扩展文件而不将其归零，因为假设超级用户进程无论如何都可以访问该数据。

然而，macOS逐渐使UNIX安全模型变得无关紧要。例如,即使是超级用户只允许访问普通用户的私人文档与用户的permission-permission给出在每个应用程序的基础上,通过保护用户和祸害的开发人员称为透明度,同意与控制(太极拳)框架。这反映了macOS赋予“root”超级用户的新含义:不再是多用户系统的管理员，就像它最初在UNIX上的含义一样，而是每个用户在执行系统管理任务时所假定的临时身份(例如，通过sudo (8))，或者运行守护进程的匿名用户［4］．

在这个新的安全模型中，不能再假定超级用户可以无限制地访问所有内容。但是，在扩展文件时不将空间归零会让超级用户处理没有权利在所有恢复任何文件已经被删除了。

macOS 11通过不再将超级用户作为特殊情况处理来解决这个问题F_SETSIZE．手册页fcntl (2)现在说:

F_SETSIZE．弃用。在以前的版本中，这将允许具有根权限的进程截断文件而不将空间归零。出于安全原因，不再支持此操作，而是将以与截断(2)．

甚至是在< sys / fcntl.h >被修改。之前(macOS 10.15 SDK):

#define f_setsize 43 / *截断文件，没有归零空间* /

之后（Macos 11 SDK）：

#define F_SETSIZE 43 /*截断文件。相当于调用truncate(2) */

据我所知，这个信息泄露漏洞从未被分配过CVE，也没有以任何其他方式公开承认，直到它在macOS 11中被悄悄地修复。

O_NOFOLLOW_ANY

甚至像系统调用这样的原始apiopen (2)还有改进的空间。macOS 11为它引入了一个新标志，O_NOFOLLOW_ANY，这将减轻整个系列的潜在漏洞，特别是在安全应用程序中。

Endpoint Security提供了已完整，解决的（无界限），每个文件中涉及的每个文件的规范化路径（像Me这样的OpenBSM退伍军人/受害者曾经知道“Vnode KPath”），但应用程序如何确定路径仍然是路径它们打开它的时间识别相同的文件？借O_NOFOLLOW_ANY集,open (2)将会出错而失败el如果任何遇到符号链接在任何地方在道路上:一个更强大的版本O_NOFOLLOW这适用于整个路径，而不仅仅是最后的部分。

结论

从我的翻找中我学到了什么?苹果仍然喜欢它的秘密;Chromium源代码仍然是所有主要操作系统提供的缓解和沙箱特性的最佳文档;不同版本仍然是寻找隐藏特性的最佳方法;有些秘密可以在显而易见的地方隐藏很长时间。

我部分地写了这篇文章作为“看看这款很酷的事情”，部分作为一种公共服务，使新的隐藏麦斯科斯队的功能不再返回搜索引擎时返回耳聋静音。即使我有一些细节错误，至少该主题现在可以辩论。

尾注

1macOS中任务和进程的关系大致可以概括为:每个(BSD)进程对应一个(Mach)进程［5］)任务，反之亦然，直到流程调用为止exec（2）．exec（2）终止当前任务，创建一个新任务并将其与流程关联，替换已死的任务。macOS的老前辈们可能会反对exec（2）实际上保持相同的任务，重置它的状态。它使用这样工作，但这是一个脆弱的设计，即给予致命的打击2016年谷歌研究员伊恩啤酒。从XNU 3789.21.4开始（macOS 10.12.1，iOS 10.1)，exec（2）创建一个新任务．

2这么古老的API有什么用?这听起来可能令人难以置信，但在终端安全之前，macOS已经没有可靠的审计机制记录进程死亡。除了acct (2)，这是一个描述为“archaic”的恭维。它将固定大小的记录记录到全局日志文件，它将进程名称截断为9个字符，它记录用户ID但不处理ID，以及流程退出时间的时间戳格式是一个字面上令人难以置信的1/64 * 8 ^指数*螳螂从过程开始的几秒(大约8年半的不间断运行，但在2:16:30标记时，精度会下降到秒以下)，16位编码为3位指数，13位尾数；进程启动时间是一个更合理的32位秒数，从UNIX纪元(从现在起17年都没问题)．我们选择不使用acct (2)．

3.强制访问控制，与“Mac”作为“Macintosh”的缩写没有关系。在历史上，MAC指的是基于军事文档分类实践的安全模型，如今，MAC是任何基于策略的安全模型的通用术语，与基于权限的安全模型(也称为DAC，或自由访问控制)截然不同并正交。macOS从TrustedBSD项目继承了它的模块化MAC框架，并以极大的热情使用它(我估计不低于七个macos11机器上的策略模块)。Linux安全模块框架相当于Linux。Windows以UWP应用程序的功能系统的形式限制了MAC。具有讽刺意味的是，由于局限于应用程序的一小部分，它是一个“强制性”访问控制系统，运行在可选择的基础上——更不用说它完全不可扩展。

4如果守护进程必须在匿名用户下运行，为什么它必须是root用户，而root用户仍然受到MAC策略的约束，可以绕过所有acl，向任何进程发送终止信号，以写模式调用sysctls，通常会造成很大的破坏?一个鲜为人知的事实是，当系统守护进程作为根运行时，它们也会运行在基于Seatbelt框架(在内部基于，你猜对了，MAC策略模块，没有想象力的命名为Sandbox)的极其严格的沙箱中。不幸的是，虽然“安全带”功能非常强大，并且能够实现非常细粒度的访问控制，但它几乎完全没有文档记录(注意到一个模式了吗?)在一个难以预测但更可悲的扭曲，它也被标记为已弃用，自OS X 10.8以来没有替代品。然而，由于所有系统守护进程都在使用它，加上谷歌Chrome和Mozilla Firefox的第三方用户，安全带似乎不太可能在短期内消失。

5Mach(与“Macintosh”没有关系)是一个用微内核替换BSD内核的研究项目。该设计被证明是不切实际的，而Mach最著名的现实实现NeXTSTEP(后来的“Darwin”、“OS X”、“macOS”)实际上运行的是Mach/BSD混合内核，几乎没有“微”。Mach是一种极具影响力的设计:Windows NT(后来的“Windows”)也是Mach的克隆，只不过经过重新设计，可以与类似vms的内核一起工作，而不是与BSD内核一起工作。Windows NT也曾尝试过微内核体系结构，但事实证明它在90年代并不比80年代更实用。