在本指南中，我们将介绍macOS 系统企业安全的各种措施，以了解其优点和缺点。

在企业中管理Mac设备的管理员和安全团队经常面临以下安全问题：

◼Mac的安全性如何?

◼是否需要第三方防护软件进行安全控制?

◼什么样的安全软件在macOS上工作得最好?

◼哪些macOS安全措施是最有效的?

我们将在以下各节讨论若干问题：

◼架构与代码设计；新的 M1 架构是否比英特尔计算机提供更高的安全性？还是在这两种架构上都可以运行macOS Big Sur上的未签名恶意代码吗？

◼Gatekeeper：Gatekeeper的作用是防止不可信代码在系统上的执行。如何防止恶意软件或恶意内部人员是绕过 Gatekeeper 的控制？

◼Notarization机制和 OCSP之间有什么区别？

◼XProtect 和 MRT：Apple 的 XProtect 和恶意软件清除工具 MRT.app 如何在现代版本的macOS，以及它们在阻止现实世界中的 ITW 恶意软件方面的效果如何？

◼透明度、同意和控制：包括全磁盘访问在内的 TCC 控制旨在保护用户数据免受进程和其他用户。他们在多大程度上实现了这一目标，以及应该怎么做？管理员知道 TCC 如何确保用户数据真正受到保护吗？

本指南将揭示 Apple 支持的各种技术中的许多安全指南。

架构和代码签名

2020 年末，Apple Mac 出现了一种新架构：Apple 制造的基于ARM 架构并被称为“Apple 芯片”。第一代，被称为 M1 Mac，M1 Mac 配备了 macOS Big Sur 11，这带来了许多安全性变化，其中最主要的是 M1 Mac 是第一款被限制运行未签名代码的 Apple 计算机。

然而，现实并非如此简单或如此安全。事实证明，至少有未签名代码可以通过两种方式绕过 M1 Mac 上的代码签名要求。其实这些都不是漏洞或绕过，而是设计出来的“特性”。

此新政策不适用于在以下环境下运行的已转译 x86 二进制文件Rosetta，也不适用于在 Intel 平台上运行的 macOS 11。这为未签名代码在 M1 设备上运行留下了两种可能性。

1.未签名的恶意软件可以通过 Rosetta 在 M1 Mac 上执行；

2.未签名的恶意软件可以通过 Ad Hoc 代码签名在 M1 Mac 上执行；

虽然 Apple silicon Mac 确实不允许本地 arm64 代码执行，除非附加签名有效，否则Rosetta 转译的 x86_64 代码不受此限制。

你可以使用简单的“hello world”程序在运行 macOS 12 Monterey 的 M1 Mac 上验证这一点。如果我们首先将下面的程序编译为 arm64e，注意操作系统是如何在缺少代码签名尝试执行时阻止它的，但是一旦我们重新编译相同的源文件作为 x86_64 可执行文件，我们可以毫无阻碍地运行我们的 hello.out：

这允许软件篡改的可能性：通过 Rosetta 转换仅作为 Intel 二进制运行的软件可能会删除其代码签名，更改其代码，并且通过 Rosetta 执行的程序没有有效开发人员的代码签名。

但即使没有 Rosetta，在 M1 上运行原生 ARM64 代码而无需使用 Apple 已知的有效开发人员证书对其进行签名的障碍也很低。 该系统允许临时签名，可以即时创建。 众所周知，像 XCSSET 这样的恶意软件就使用了这种技术。 在不知情的用户运行良性的第一阶段有效负载后，恶意软件会下载恶意有效负载并在内存中对其进行签名，以便它可以在 M1 Mac 上执行而不受 Apple 代码签名检查的干扰。

简而言之，使用基于M1芯片而不是英特尔芯片的mac确实可以获得一些安全优势，如果你在Mac上运行安全软件，确保它是为M1编译的架构而不是通过 Rosetta 运行。然而，这一特性已经被攻击者发现。

Gatekeeper

Gatekeeper 阻止不需要的程序执行的能力依赖于容易失效的机制，这些机制可以被恶意内部人员利用或没有管理员权限的恶意代码覆盖。

macOS 包含一项名为 Gatekeeper 的技术，旨在确保只有受信任的软件才能在Mac 上运行。

Gatekeeper 实际上是命令行工具 spctl 的前端，它管理安全性。spctl 维护和评估确定系统是否允许对系统上的文件进行安装、执行等操作。

用户通常通过“系统偏好设置”应用程序通过“常规”与 Gatekeeper 交互安全和隐私选项的选项卡：

实际上，用户可以设置系统策略，允许从任何地方下载应用程序来安装，在命令行上通过spctl打开并执行，这是苹果公司故意阻止的。如果用户拥有管理凭证的话，大多数都害怕命令行。

不幸的是，对于安全团队来说，密码要求是完全没有必要的。虽然是需要更改该系统范围的设置，对于任何给定的用户来说，这不是必需的，攻击者可以覆盖该设置并通过以下方式下载和执行不受信任的软件。Gatekeeper 系统策略旨在由用户覆盖，无需验证。

Apple 的安全控制措施从未考虑过企业用户，Gatekeeper底层的设计方式背后的假设是“管理员”和“标准”用户是同一个人操作两个帐户。

我们可以求助于一些常见的macOS恶意软件来说明如何实现这种“绕过”。在 macOS 11 Big Sur 之前，恶意软件安装程序通常只提供如何从 Finder 中启动不受信任以及无需提升权限的应用程序的说明。

这在 macOS Monterey 上仍然如此，并且在 macOS 的下一次迭代中可能仍然如此。自 Big Sur 以来，Bundlore 和 Shlayer 等恶意软件运营商消除了这种复杂性，使用了绕过整个安全评估策略的意外绕过漏洞（CVE-2021-30657），基本上允许任何缺少 Info.plist 的应用程序包和一个 shell 脚本可执行文件（与通常的 Mach-O 文件相反）以避免被 macOS安全政策检查。该漏洞仅影响 Apple 自己的内置安全机制。使用该技术的恶意软件仍然会被可靠的第三方安全解决方案（例如 SentinelOne）检测到。

还有其他著名的方法绕过Gatekeeper。整个策略依赖于在下载时使用扩展属性(com.apple.quarantine位)给下载的文件打上标签。正是该属性在文件上的存在导致Gatekeeper开始其检查，所以如果隔离位在程序执行之前丢失或删除，Gatekeeper将永远不会启动操作。

此属性需要由下载应用程序（例如，浏览器、邮件客户端等）附加到下载的文件中。 但是，像 curl 这样的命令行工具不执行此功能。 同样按照设计，安装程序包还将删除已安装可执行文件上的隔离位。 第三方文件提取 GUI 应用程序也可以选择不选择将隔离位添加到下载中。

公平地说，大多数 GUI 应用程序确实会标记下载的文件，但是由用户或其他进程删除隔离位也不需要提升权限，因此即使是标准用户或以标准用户身份运行的进程也可以将 Gatekeeper排除在外。

如上所述，即使是非管理员、无特权的用户和进程也可以通过多种方式绕过 Gatekeeper，方式相对轻松。一般的策略只是说服不知情的用户运行一些看似无害的程序，然后通过 curl 下载恶意负载并执行它。

一些 macOS 恶意软件安装程序甚至不厌其烦地确保任何文件隔离属性被删除，如本例中的 Bundlore 脚本。

我们将在下面再次讨论隔离位，因为它在其他 Apple 安全层中发挥作用，总之，Gatekeeper 阻止恶意软件执行并不成功。

Notarization机制和OCSP

在 Notarization 机制采用之前，macOS 使用 Gatekeeper 来阻止从互联网上下载的应用程序启动，Gatekeeper 是山狮中引入的一项新安全技术，它可保证用户安装来自 Mac App Store 或者拥有开发者签名的应用。具体来说，它可以作为 Mac App Store 的应用鉴别工具，也可识别来自 Mac App Store 以外应用的开发者身份， 从而防止一些恶意软件的进入。使用 Gatekeeper 时， macOS 会记录那些有问题的已知应用程序列表，并防止其被执行。但是，在应用程序通过 Gatekeeper 并得到用户批准后，Gatekeeper 就会失效，很难检测到现有的二进制文件是否被感染，并且没有好的方法可以撤销应用程序的批准。因为一旦开发人员上传的证书被撤销后，Mac App Store 就会撤销所有开发人员上传的应用程序。为了出现这种歌情况，苹果引入了 Notarization 机制，来强化对开发者及其上传应用的管理。简而言之，Notarization 机制是建立在当前 Gatekeeper 安全检查之上的一个新验证层，是 Gatekeeper 技术的补充。在 Mojave（10.14）之前，苹果只需要一个注册的 Apple ID 代码签名，就会完全信任上传的应用程序。而实行 Notarization 机制后，苹果现在还会检查提交的代码中是否存在 " 已知恶意应用程序 " 和 " 可能阻止你的应用程序正确安装的常见代码签名问题。" 通过这些 ( 目前可选 ) 额外检查的应用程序，就被认为是 " 经过了 Notarization 机制 "，即它们是安全的。

OCSP是TLS协议的扩展协议，在TLS的使用中，客户端无法判断一个还没有过期的证书是否被吊销了。因为CA在颁发了证书之后大部分情况下都是等待这个证书过期了之后的自然失效，而如果CA出于某些原因要人为的吊销某个证书就没有了办法。这个时候客户端在从服务端拿到了一个证书之后，去找服务端的接口去验证一下这个证书的是否过期这一信息。

当用户试图访问一个服务器时，OCSP（在线证书状态协议）发送一个对于证书状态信息的请求。服务器回复一个“有效”、“过期”或“未知”的响应。

Notarization机制和 OCSP 虽是两种完全不同的技术，但两者都涉及对已经通过或通过Gatekeeper 的签名代码进行在线检查。

现在，所有希望在 macOS 上传播签名代码的开发人员都需要通过Notarization机制检测。该技术在 Catalina 10.15 中作为选择加入首次出现。未签名的代码不会进行Notarization机制检查。但对攻击者来说，只需加入签名代码即可实现恶意软件的合法性。这反过来又可以帮助恶意软件实现其他目标，例如持久性、提升权限和设备配置更改。

目前已经出现过许多利用Notarization机制进行攻击的示例。

然而，通过Notarization机制并不一定意味着必须通过在线检查。其他在野外看到的方法是避免在线检查发生，早期版本的 macOS 上的 XProtect，Notarization机制检查依赖于附加到包含代码的文件的扩展属性。正如我们在 Gatekeeper 中看到的那样，可以通过 curl 下载。在此示例中，未附加 com.apple.quarantine 扩展属性，或使用内置的 xattr 实用程序删除该属性。同样，后一种方法不需要提升权限，并且可以由标准用户或其他以标准用户权限运行的进程执行。

Notarization机制不是 Mac 设备在代码启动时执行的唯一在线检查。单独的检查称为 OCSP 或在线证书状态协议，由macOS 信任守护进程。

trustd 和 OCSP 的目的是检查正在启动的软件是否有被吊销的开发者证书。这意味着当 Apple 吊销开发者证书时，所有软件，包括非恶意应用程序使用该证书签名将无法通过 OCSP 检查并被阻止启动。

吊销开发人员证书是 Apple 处理已知恶意软件的一种方式。通过使用 OCSP响应者服务，苹果希望阻止任何开发者证书，与 Notarization 和 Gatekeeper 不同，吊销服务不依赖于 com.apple.quarantine。但是，OCSP 也有其不足之处值得我们注意。

恶意软件可以通过两种方式绕过 OCSP 检查。最简单的就是删除代码签名。虽然这会带来其他障碍，但很有可能运行。第二种绕过 OCSP 的方法比较麻烦，但仍然可以实现。检查只发生在代码的实际启动序列期间，自然需要互联网连接。如果在恶意软件启动期间设备暂时离线，那么受信任的服务将跳过检测。

一旦代码启动并运行，设备就可以重新上线。虽然不再可以通过命令在未经授权的情况下更改网络设置，程序仍然可以写入主机文件并阻止所有或选定的网络调用。

echo 127.0.0.1 ocsp.apple.com | sudo tee -a /etc/hosts

如上所述，Notarization机制和 OCSP 证书检查都可以被恶意软件破坏。

本文翻译自：https://www.sentinelone.com/wp-content/uploads/2021/11/The-Complete-Guide-to-Understanding-Apple-Mac-Security-for-Enterprise.pdf如若转载，请注明原文地址