macOS 安全性改进

（MAC OS关于安全性的改进）

大家早上好

感谢大家今天来参加我们的演讲

我是Garrett 我在Apple安全工程 和架构团队工作 今天我们要讲 macOS Catalina中 关于安全性的一些改进

这是本场演讲的进度安排 我们要深入地讲一下 纵深防御的安全性原则 以及如何在macOS中实施 安全防御原则 然后我们要深入macOS 安全模型的两个截然不同的部分 Gatekeeper 和用户隐私权保护

让我们先从纵深防御开始讲 （纵深防御） 对于macOS这样一种既复杂 又有很多用例的产品来说

没有任何一种技术或功能 可以独立提供完美的安全性

因此在设计macOS时 考虑到了安全性的许多不同层面 每个层面都有具体的目的或目标

并且每一年我们都会改进 每一个层面的技术和政策 从而保证你们的安全

这就是纵深防御的原则的一个应用

目标是确保其中一个层面的 安全保护失败 不会破坏系统的整个安全模型

相反 我们依赖于通过不同性能 提供多重保护 有些层面可以拖延攻击者的前进

其它层面可以减少某组件的攻击面 有一些层面可以创建阻碍 可以让它更轻松地防御特定资产

今天我们在这里要谈macOS中 关于安全性的两个截然不同的层面

首先我们先稍微讲一下 Gatekeeper 它是安全性的一个很重要的外部层面 用于第一时间防止恶意软件 在你的系统上运行

然后我们会讲用户隐私权保护 用于确保即使恶意软件 能应付Gatekeeper 它也不一定可以访问 绝大多数敏感性数据和资源

让我们讲一下Gatekeeper

初次引入Gatekeeper时 与开发者ID程序一起 它的目标是防止广泛的… 防止爆发 防止恶意软件的广泛爆发

但多年以来 它的目标有所扩大 现在它用于保护用户 不运行恶意软件 并让用户控制 他们在Mac上所运行的东西

它的具体实现方式在多年以来 也发生了变化 虽然有很多细微差别 但Gatekeeper的意图通常 可以归结为几个简单的问题

我们谈谈如今Gatekeeper 是如何实现这个目标的

有四件事我们认为是 Gatekeeper扫描的一部分

第一件事…

第一是恶意内容扫描

从而确保在即将运行的app中 没有任何已知的恶意内容

第二是署名验证 从而确保app没有被篡改 因为开发者对它署名了

第三是身份验证 我们正是用这个来强制实施计算机的 本地安全性政策 如果用户选择了 他们只希望运行 来自App Store 或已认证的开发者的软件 我们就不允许运行由其它任何人署名 或根本没有署名的软件

最后是首次启动提示 这是为了确保用户实际上希望 运行这个app

如果我们不讲 Gatekeeper何时检查 我们就不能讲 Gatekeeper检查什么

在macOS Mojave中 Gatekeeper在经由 LaunchServices启动 隔离软件的首次启动时运行它的扫描

为了更好地理解 我们需要深入了解一下 隔离是什么意思 以及它对于经由LaunchServices 启动意味着什么 让我们看一下吧

隔离是一种技术 它嵌入在macOS中用于标记 从设备以外的其它地方 到达设备的文件 当你从web浏览器中下载文件时 或当某人通过iMessages 给你发送某些东西时 或如果你进行隔空投送 那些文件都会被隔离

此外 macOS将向那个文件添加 关于它的来源的元数据

当我们呈现首次启动提示时 我们可以为你提供 关于文件来源的更多情境

现在隔离是一个选择加入模型 那意味着app 需要选择加入才能隔离 它们放在磁盘上的文件

这通常意味着当app在后台下载时 作为比如自我更新的一部分 那些文件通常永远不会被隔离

有个例外情况 除非app是沙盒化app 因为默认隔离沙盒化app的文件

这会帮助你更好地了解系统上 哪些文件会被隔离 现在让我们谈谈启动服务

启动服务是一个框架 用于发现并启动app

通常在你能想到的在Mac上 启动app的绝大多数方式中 都使用了启动服务 比如当你在Finder 或Dock中打开app时 将会使用启动服务

如果你使用了 NSWorkspace API 通常也会使用启动服务

当app经由文档处理器 或直接经由URL打开时 都会使用启动服务

在接下来的演讲中 当我具体讲经由启动服务路径的 某些东西时 我将使用这个Finder图标

但还有许多加载代码的方式 不经由启动服务

这是其中一些例子但并不详尽 包括使用NSTask来启动进程

或exec和 posix spawn的调用

或使用NSBundle API 向进程中加载库 用于加载或dlopen

在接下来的演讲中

当我提及不经由启动服务路径 加载代码时 我将使用这个终端图标

现在让我们以一种 更容易谈论今年的变化的形式 迅速总结一下 关于Gatekeeper的信息

在这里我们可以看到 在启动服务路径上 隔离软件首次启动时 Gatekeeper的行为 和macOS Mojave Gatekeeper 将实施恶意内容扫描 和署名检查 以确保没有任何已知的 恶意内容 以及app没有被篡改过

然后它会实施本地政策检查 默认情况是app必须 由开发者ID证书 或由App Store进行签名

最后它会给用户呈现首次启动提醒 从而用户必须批准app

从最新发布的macOS Mojave 10.14.5起

默认政策发生了轻微的改变 新的Mac开发者证书 要求他们的软件必须经过公证 才能通过Gatekeeper

这就是我们在macOS Catalina 中的第一个改进 我们扩展了这个政策 从而所有新软件都需要进行公证

在这种情况下 “新”的意思是 在2019年6月1日以后签名 或创建的软件

这意味着全部现有软件将继续通过 Gatekeeper 不予改变 只需要开发者ID证书签名即可 但所有新软件必须经过公证才能通过 Gatekeeper

现在… 我们在macOS Catalina中 所做的下一个改进是 Gatekeeper将扩展到 在所有隔离软件上强制实施 同样的政策

那意味着无论 软件是如何加载的 如果它是隔离软件 它必须包含无已知恶意内容 它必须没有被篡改 新软件将需要进行公证

首次启动政策也有些微改变 我们不要求用户批准 独立的可执行文件或库的首次启动 但对于所有捆绑软件来说 都将显示首次启动提示

因此现在 Gatekeeper扩展到了 扫描所有隔离软件 并在所有隔离软件上强制实施政策

这就把我们引向我们在macOS Catalina中做的最后一改进

Gatekeeper将为你 提供进一步的保护

通过确保所有软件都进行了 恶意内容扫描来实现

那意味着无论软件是否被隔离 无论代码是如何加载的 只要找到任何已知恶意内容 软件都将被阻止…并且会警告用户

这就是Gatekeeper 在macOS Catalina中的所有扩展 从而为你提供保护

重点是要记住一件事

我们的目标是默认保护每一个 Mac用户的安全

而不是阻止你想在 Mac上运行的软件 （你总是可以选择在你的系统上 运行任意软件） 那意味着总是有一种方式 可以让你运行 你想在你的系统上运行的特定软件

刚才我稍微提了一下 我们一直持续不断地改进 每个层面的技术和政策

我还想花点时间稍微提一下

Gatekeeper的下一个改进

现在我们安全工程团队 有一个很大的目标 我们想让macOS 和iOS一样安全 同时仍保持 你所期待的Mac的所有灵活性

那代表着一些非常有意思的挑战

但有一件事变得非常清楚

平台的安全性已经变得越来越依赖于 代码签名的有效性了

这意味着如果app没有签名…

将不可能检测到篡改

更进一步 如果捆绑签名在运行时损坏

当In-Out在运行时自我修改时 将很难区分恶意篡改和一般篡改

在未来版本的macOS中 将默认不再运行任何无签名的代码

为了实现这个目标 你们可以做一些事情 来帮助改善平台的安全性

首先是签署并公证你所发布的 所有软件 即使它目前没有被隔离

（我们需要你们的帮助） 第二… 不要在运行时损坏app或捆绑签名 如果你需要更新app 请确保最后的结果是磁盘上的app 仍进行了适当的签名和公证

最后请记住加载代码可能会失败 如果你尝试加载隔离库或进程 而用户选择不运行它的话 那将会运行失败 请确保你的app 会优雅地处理这些失败

这就是Gatekeeper的 所有扩展 从而尝试防止在你的Mac上 运行恶意软件

现在让我们邀请Kelly上台 讲一下在用户隐私权保护方面的改进 （用户隐私权保护） Kelly

嗯 谢谢Garrett 大家早上好 我是Kelly Yancey 我和Garrett都是 Apple安全工程 与架构团队的一员 去年在WWDC 2018时 我很荣幸地介绍了 macOS Mojave中的 新的隐私权保护 具有广泛特征…抱歉 让我们回顾一下 这些保护用于提高用户 对于如何访问他们的数据的透明度 并为用户提供对那些访问的控制 今天我能再次回到这里 我感到很激动 我要与大家分享我们在 macOS Catalina中所做的改进

具有广泛特征

隐私权保护要求用户准许 访问可能会记录用户的硬件 比如摄像头或麦克风

或准许访问用户的隐私敏感文件 或文件夹 比如照片、邮件或消息

此外还保护 自动化其它app的能力 从而用户可以控制在app之间 如何共享他们的数据

今天我想先讲记录功能

自macOS Mojave起 在app访问摄像头或麦克风之前 必须先经过用户准许

然后在 macOS Catalina中 进一步要求用户准许记录 他们屏幕上的内容 或他们在键盘上键入的键

这很重要 因为这就好比我们不希望人们 “肩窥”一样 越过我们的肩膀来看我们正在做什么 或正在输入什么 我们不希望app偷窥 我们的联系信息、银行信息 或密码等等 无论是有意或无意的

我们该如何实现呢？ 让我们先看一下屏幕记录

这是使用 CGDisplayStream 实时记录显示屏上的内容的简单示例 在macOS Catalina上 这个app首次运行时… 将会执行创建 CGDisplayStream的调用 它将返回无 并显示一个对话框 指导用户进入安全和隐私首选项

如果用户希望app记录屏幕的话 用户可以批准它这样做

当读取其它app窗口中的内容时 也一样 比如有个功能是把窗口中的内容 保存为磁盘上的一张图片

很显然 对CGWindowListCreateImage的调用

可以返回无 前提是如果给它传递的窗口ID 不属于发起调用的app 并且也不属于桌面背景图 或菜单栏 我想强调的是 这是背景图 它不包含桌面上的任何图标 或任何文件的名称

可能会给用户显示授权对话框 指导用户批准app 进行屏幕记录 因为对话框只在首次记录时显示 CGWindowListCreateImage 或CGDisplayStream 可能会由于没有批准屏幕记录而失败

我要讲的另一个 与屏幕记录相关的外围话题是 窗口元数据

app可以使用Core Graphics框架的 CGWindowListCopyWindowInfo函数 查询关于屏幕上打开或处于后台的 窗口的元数据

所返回的元数据包含 窗口的尺寸和位置 和唯一的窗口标识符 以及拥有窗口的app的 标识符的名称和进程

然而窗口名称和共享状态不可用 除非用户预批准app可以进行 屏幕记录 这是因为有些app会在窗口名称中 添加一些敏感性数据 比如账户名称或更可能是网页URL

并且CGWindowListCopyWindowInfo 永远不会触发授权提示 但它会过滤它给调用它的app 所返回的元数据 因此如果你的app依赖于 获取窗口名称 比如说 你会发现所返回的元数据 不包含窗口名称 你可能想警告用户并把用户指向隐私 安全与隐私首选项设置

这里有一个示例函数 在每次显示中都可以获取 桌面背景图的唯一窗口标识符 再一次 背景图 不包含桌面上的图标

这个函数首先会获取屏幕上 所有窗口的一个列表 使用CGWindowListCopyWindowInfo 函数实现

然后它获取 Core Graphics 用于桌面背景图窗口的窗口级别 或Z序

然后再过滤整个窗口列表 只保留桌面背景窗口级的窗口

如果你从网上查一下 你会发现许多代码样本 都是按kCG窗口名称过滤的 因为窗口名称可能包含 隐私敏感性信息 可能要求用户预批准app 进行屏幕记录

然而通过以窗口级别而不是窗口名称 识别桌面背景窗口 无论用户是否预批准app 进行屏幕记录 都能进行识别 这正是app设计的小修改 可以导致用户体验的 大改变的一个例子 （Catalina中的记录保护）

这是macOS Catalina 保护你屏幕上的内容 不经你允许就被记录下来的方式 app可以自由记录 它们自己的窗口中的内容

菜单栏和桌面背景图

但用户必须使用 安全与隐私首选项设置 预批准app记录整个屏幕 或除它们自己的窗口之外的 窗口的内容

我想讲一下 在macOS Catalina中 受保护的其它记录功能：你的键盘

现在绝大多数用户都期待 他们的键盘 只能用于他们所交互的app 也就是处于最前的app 并且绝大多数app都仅当用户 正在使用它们时才会要求键盘输入 事实上如果你的app使用了 标准的UI组件 它们会自动处理 提交到你的app的键盘事件

有些app希望能在键盘事件 提交到app时进行拦截 这没问题 可以通过创建 NSApplication的子类 并覆盖sendEvent方法实现 或像这里所显示的这样 你可以使用NSEvent的 addLocalMonitorForEvents函数实现

监控所有键盘事件 包括其它app的键盘事件 然而 这需要用户批准

在这里你可以看到一个使用 CGEventTapCreate的例子

用于调用按下和释放键事件的回调

这段代码首次运行时 这个调用CGEventTapCreate 将失败并返回无

与此同时给用户显示一个对话框 把用户指向安全与隐私首选项设置 用户可以批准你的app在后台监控 键盘事件 如果他们愿意的话

app可能会检查授权状态 而不需要触发批准提示

使用 IOHIDCheckAccess函数 和kIOHIDRequestTypeListenEvent 参数实现

并且app可以请求显示一个 批准对话框 而不需要使用IOHIDRequestAccess 函数和同一个参数 创建一个事件标签来尝试发布事件

总的来说 macOS Catalina 现在要求用户准许 app记录他们屏幕上的内容 或他们通过键盘进行的键入 （用户隐私权保护记录功能） 现在我想让你们注意一下 macOS如何保护 对你们的隐私敏感性文件的访问

macOS Catalina 继续采用Mojave中的方法 对用户的文件和文件夹的 隐私保护提供两大级别 第一 app通常可能 访问的用户数据 比如联系方式或照片 对于这些数据 macOS将在 与app共享数据之前 确认用户的准许

第二 还有一些用户数据 这些数据在文件系统中只是 一些事实细节 并不是API的一部分 诸如邮件、消息 或Safari浏览历史 要访问这些数据 需要跨过很高的障碍 因为这些文件 一般只能由指定app访问 比如磁盘管理或备份实用程序

但首先让我们谈谈需要用户批准 才能访问的文件和文件夹

macOS Mojave 引入了用户准许要求 用于通过文件系统访问你的 联系方式、日历、提醒或相册 当app尝试访问这些类别中的 任何一个类别的文件时

看起来就是这样一个提示

这与我们刚才看到的 用于屏幕记录和键盘事件记录的 授权对话框不一样 调用线程实际上宁愿被阻止

也不愿意停止访问并给用户显示警告 它会等待用户批准或拒绝app 对该类别的文件的访问

在macOS Catalina中 我们给这些类别补充了 这些额外的类别 包含在系统中用作API的数据

这些代表用户用于存储文档的 不同位置

他们在Finder中双击

通过打开或保存面板进行选择 等等

用户的桌面和文档文件夹 是主要保护对象 因为那是许多用户保存文件的 默认位置

并且因为某些app 包括Safari 在下载时默认把所下载的文件 保存在桌面上

同时也要保护在 iCloud Drive中保存的文档 或在第三方云存储中保存的文档 或在可移除空间中保存的文档 并且如果你像我一样经验丰富 你看能会考虑保护软盘上的文档 但在这里我是指可能会被移除的 任何存储 包括USB拇指驱动或外部磁盘

并且我相信摄影师可以证明 有些人一辈子都使用外部磁盘 或使用网络附加的存储

因此macOS Catalina 现在也保护 我们用于存储文件的绝大多数 常见的位置

现在… 用户不需要批准app 在任意受保护的位置创建新文档

只是为了读取现有内容

文件内容已经存在了 比如说文件传输app 可以继续把新文件保存到用户的 下载文件夹中 而不需要出发准许提示

macOS Catalina中的 用户隐私权保护

现在支持用户意图的概念

当在Finder中双击文件时 当从另一个app中进行拖拽时 或当在打开或保存面板中选择文件时 都会推断用户意图

并且当用户实施任意一种上述动作时

在文件受保护的地方实施 上述任意动作

你的app都将访问用户所选的 一个或多个文件 而不需要触发准许提示

让我们看一下相对于用户准许而言 Catalina如何推断用户意图

抱歉 首先用户准许是被动的 只有当app尝试读写文件时 才能被授予访问权限 然而用户意图是主动的 甚至在app试图读写文件之前 就被授予了访问权限

并且用户准许提示可能会中断 用户的流程 然而用户意图是从标准的UI交互中 推断出来的

为了尽可能减少这些中断 用户准许可应用于所有数据 比如说 你桌面上的所有文件 然而用户意图仅针对 用户所交互的一个或多个文件 进行推断

尽管如此 这两者并不相互排斥 只要你的app访问它所创建的文件 或用户所选的文件 就不需要触发准许提示

但如果你的app要访问处于 隐私受保护位置中的文件 而不是它自己所创建的文件 或也不是用户所选的文件 用户就需要通过准许提示 批准那个访问

有一个常见的情境 app可能需要访问用户所选的 不止一个文件 即附带文件

比如自动打开与电影文件名称相同的 字幕文件 但字幕文件位于电影文件旁边

因此使用NSFileCoordinator中的 相关项支持

可以推断对一个文件的许可 可以扩展到对其它文件的许可

要使用NSFileCoordinator 打开附带文件 你首先需要在你的app中声明 附带文件的扩展名

CFBundleDocumentTypes Info.plist 密钥 并把NSIsRelatedItemType的 布尔值设为真

然后在你的代码中

创建NSFilePresenter 的子类

把primaryPresentedItemURL 设置到用户所选的文件上 也就是你的app 已经拥有访问权限的那个文件 并把PresentedItemURL 设置到附带文件上 也就是你想要访问的那个文件

请注意 附带文件的扩展名可以 与用户所选文件的扩展名不同 但所有其它组成部分都必须相同

最后 创建NSFileCoordinator 以引用NSFilePresenter实例

当你调用NSFileCoordinator的 协调方法时 在那一段时间内 你的app同时也会获取 对附带文件的访问权限

这是关于app如何使用 NSFileCoordinator 来获取拥有文件名称相同 但扩展名与用户所选的文件不同的 文件的访问权限的简单介绍 而不会触发用户准许提示

为了安全地推断用户意图 现在打开并保存面板总是处于 进程之外

因此类继承和视图等级就发生了改变 这可能会对你的app产生影响 如果你有NSOpenPanel 或NSSavePanel子类的话

app将再也不能 通过调用OK方法显示面板 用户必须自己操作

NSOpenSavePanelDelegate方法 也有些微的修改

app再也不能使用这个方法来重写 用户选择了

访问URL提供给这些方法的文件 可能会触发用户准许提示 因为这些方法是通过面板进行调用的

而在此过程中用户仍正在与面板 进行交互 因此他们还未选择文件 因此你的app还未被授权访问

现在app可以测试指定文件 是否可读 或可写 而不需要使用这些API 触发准许提示

只要你的app仅访问 它自己所创建的文件或用户… 通过文件打开事件或拖放 或打开面板或保存面板选择 而接收的文件 将推断app被许可访问这些文件 并且没有必要显示准许提示 然而 如果需要显示准许提示 所有新的受保护的文件系统位置 都支持目的字符串 你可以在Info.plist中 指定目的字符串 用于解释当显示准许提示时 访问的情境

用于这些类别的目的字符串是可选的 如果你的app要访问其中一个 受保护的位置 是有意地访问 我们强烈推荐你对该位置添加 目的字符串 从而用户了解app为什么要访问 他们的文档 如果你发现在你的测试中 你的app触发了 你不希望触发的准许提示 你可以点击“不允许”按钮 并进入控制台app 并查找所产生的沙盒冲突 那会告诉你app所尝试访问的文件 并回溯导致它

需要显示准许提示的根由

这即macOS Catalina 如何保护用户的文档 以及标准UI如何 以及如何使用标准UI交互 推断他们期待app访问哪个文档

让我们看一下macOS如何保护 由系统管理的用户数据 以及app如何请求访问那些数据 如果必要的话

在这里我们看到 自macOS Mojave起 就受保护的数据类别

一些软件 比如磁盘管理或备份软件 需要处理所有文件 无论文件内容是什么

并且那些软件… 那些app可以使用与我们刚才 看到过的API相同的API 用于决定给定文件是否可读或可写 然后取决于什么适合app 它们可以跳过不可访问的文件 或它们可以警告用户 并指导他们 在安全与隐私首选项设置中 批准app获取完整权限

这就是用户批准完整磁盘权限的地方

既然我们已经到这了 我想讲一下我们在 macOS Catalina中 所做的一个改进

我们改进了用户批准app 获取完整磁盘权限的方式 同时用户仍可以使用这个加号按钮 手动向列表中添加app

我们从开发者们那里得到的 其中一个反馈是 用户找到他们的app的 特权helper 可能会很尴尬

因此 在macOS Catalina中 由于缺乏完整磁盘权限批准 而被拒绝访问的可执行文件 现在可以未经检查就进行预填充

在这里我们看到这样的helper 可通过它的可执行文件名称识别它

如果那个helper嵌入到 一个捆绑包中 将显示指定捆绑包 Info.plist的 图标中的显示名称

再一次 被预批准获取 完整磁盘权限的app 可以访问这个数据 app使用FileManager 或POSIX级API来测试授权 并且如果有必要的话 还可以指导用户进入 安全与隐私首选项设置

用户可以在那里批准app的权限 如果他们愿意的话

在Catalina中 需要预批准完整磁盘权限的数据 已经进行了扩展 从而包含垃圾数据

许多人认为只要他们把文件 移到回收站中 文件就消失了 因此他们所期待的最后一件事就是 有一个东西能深入到他们的 垃圾文件中

这太吓人了

与其它类别的数据一样 垃圾数据可能包含大量 隐私敏感性数据 然而与其它类别不同 垃圾数据以文件为中心 并确实有操纵这些文件的API 诸如这样的API

会把文件移到用户的回收站中

现在我想稍微深入地讲一下 FileManager回收项API 它把文件的URL作为参数 从而把它移到回收站

调用参数的app需要已经获取 对该文件的访问权限 你不能把你自己 都没有权限访问的文件 移到回收站

但如果成功 它会在文件在用户的 回收站中的新位置上 用文件的NSURL 填充输出结果的URL参数

并且它仍可以访问那个URL 为了讲得通 它在把文件移到回收站 之前拥有对那个文件的访问权限 在它把文件移到回收站之后 它仍然还有那个文件的访问权限 这就可以让你使用 FileManager API 比如 把文件从回收站中移回去

总而言之 当app要求完整磁盘权限 来枚举回收站中的文件时 或来查看那些文件内容时 不需要任何授权就可以把文件 移到回收站 或访问它们之前放在回收站中的文件

最后我要简单讲一下自动化

macOS Mojave 引入了系统或其它app的 自动化准许要求 这对于防止恶意软件滥用你所信任 并与之共享数据的app来说 非常重要

首先是合成事件 合成输入事件 一般由可访问性软件用于提供

对键盘或鼠标输入的帮助

但因为用户准许对话框 用户意图界面或其它各种安全性提示 都依赖于用户输入 合成输入事件仅被允许发生在 用户所安装的用作代理的app中 这一点很重要

这里有段示例代码…

这是一个代码示例 模拟… 按下键和释放键

这段代码首次运行时…

并尝试发布这些事件时 就好像是用户实际上正在键入一样

这些事件被丢弃了

并给用户显示类似这样的对话框 警告用户 他们需要进入安全与隐私首选项设置 授权app获取可访问性功能

之前我们看过这段 用于监听键盘事件的示例代码

如果我把 listenOnly参数改为

defaultTap…

就像那样的

CGEventTapCreate 会创建一个修改事件轻触 而回调可以改动事件流 这意味着现在你的app有一种 可以影响 向系统的其余部分 提交哪些事件的方式

而仅监听事件要求输入监控的授权 修改事件轻触 要求可访问性功能的授权

app可以测试用户 是否已批准app 合成本地… 合成输入事件 通过 IOHIDCheckAccess函数实现 这与检查键盘输入监控授权的API 是同一个API 但你可以在这里看到我们传递了 kIOHIDRequestTypePostEvent

因此这通过合成事件自动化了 现在让我们谈谈通过Apple事件 自动化app

在app用AppleScript 或原生Apple事件 来控制其它app的动作之前 必须经过用户准许

这些准许提示指明了 哪些app处于哪些其它app的 影响之下 并为用户提供了对那个自动化的控制

但没有为发送进程

提供隐私敏感性数据的访问权限的 Apple事件例外

许多这样的时间都经由 NSWorkspace API暴露

AEDeterminePermissionToAutomate 目标函数

可用于测试向目标app发送 Apple事件 是否需要授权

这里有个例子 测试调用者是否可向Keynote 发送任意Apple事件

通过传递布尔值为真 对于 askUserIfNeeded参数 你可以请求… 如果必要的话就触发批准提示

但我要指出的是如果显示了提示 发起调用的线程将被阻止 并等待用户的交互 因此你一定不想在app的主线程上 调用这个API

这个API的级别很低 它会返回一个 OSStatus代码表明 调用者是否被允许向 目标Apple事件

尝试发送Apple事件 是否会触发提示 以确认用户的准许 或目标当前不在运行 而尝试发送可能会导致启动目标的 Apple事件

或是否产生某些报错

这是关于macOS 在允许app自动化其它app之前 如何捕捉用户的准许 以及app如何决定是否提供准许 并进行相应的调整的快速总结 （Catalina中的 新用户隐私权保护） 在macOS Catalina中 需要用户准许才能记录 用户的屏幕或键盘 这对于现有的摄像头和麦克风保护 来说是新添加的功能 现在许多常用的位置… 也保护许多常用的 用于保存文档的位置 比如用户的桌面文档下载 他们的iCloud Drive 或第三方存储 可移除的网络空间以及 当然了 还有回收站

我们在macOS Catalina中也扩展了 隐私权首选项政策控制 MDM有效载荷 以包含新的受保护资源的服务 我想指出在开发过程中 你可能想触发— 当你测试app的行为时 你可以再触发提示 并且你可以使用与你在左侧看到的 服务名称相同的服务名称 通过tccutil命令行工具 分别为受保护的资源重设提示状态 （总结） 之前 我们从Garrett那里了解了 关于Gatekeeper的改进 我们只讨论了一些… macOS Catalina中 用户隐私权保护方面的改进

我想回顾一下

请记住一定要对你所发布的 所有软件都签名并公证 并且一旦被签署 请不要修改那些捆绑包 如果你确实需要修改捆绑包 请一定要把修改转换到另一个 也被签署了的捆绑包中

对于用户隐私权保护 请尝试尽可能地利用标准UI 一定要处理报错 API可能会返回 如果用户…抱歉 处理API可能会返回的任何报错 如果用户拒绝准许的话 请记住一旦用户授权你的app 访问他们的个人数据 保护他们隐私权的责任就转交给你了 因此请谨慎处理用户的数据

非常感谢你们 希望你们享受 本周WWDC余下的时光 演讲结束之后就有一场 关于安全性的实验室 欢迎大家参加 若你有关于macOS中的安全性或 其它隐私权或安全保护方面的疑问 非常感谢