论证：iOS安全性，为什么需要审核？

2021-05-28

本文首发于论证：iOS安全性，为什么需要审核？ - 掘金，欢迎关注我们 @37手游iOS技术运营团队。

一、前言

最近，Epic Games vs Apple 的诉讼大战非常的激烈精彩，报料的内幕消息也十分劲爆！满足了一波炎炎夏日的吃瓜群众，当然作为技术人员，我们除了关注瓜甜不甜，还要分析这瓜为什么甜？

Epic Games 邀请了一位专家证人，针对“iOS安全性”这个问题进行展开辩论，即：苹果可以让 iOS 系统，在应用分发和第三方访问等方面更像 macOS，也不会在安全性方面受到影响。

二、正文

2.1 辩论者

针对这个辩题：“iOS 本可以和 macOS 一样开放，不‮安受‬全性影响”（iOS could be like macOS without security drawbacks），我们先来看看辩论者，Epic Games 的专家证人，哈佛‮学大‬计算机科学教授 James Mickens，这是何许人也？

大家对 James Mickens 教授可能不太了解，没有关系！我们可以通过维基百科一起来看看：

James W. Mickens 是美国计算机科学家，是哈佛大学约翰·A·保尔森工程与应用科学学院的 Gordon McKay 计算机科学教授。他的研究重点是分布式系统，例如大规模服务以及使它们更安全的方法。他对将机器学习作为解决最突出的计算问题的样板解决方案持批评态度。

另外，八卦一下，“Gordon McKay” 这个头衔：戈登·麦凯（Gordon McKay）是一位富有的商人，他向哈佛捐赠了一大笔钱，这笔钱被存入了一个信托基金。该基金的资金用于支付哈佛的40个不同的教授职位。拥有戈登·麦凯授予的椅子的人——即受雇于哈佛大学教授的人，其职位由戈登·麦凯设立的信托基金资助——将拥有“戈登·麦凯教授”的头衔。引用来源：What is a ‘Gordon McKay Professor’? - Quora

针对辩论者 James Mickens 教授的介绍，大家可以知道，他关注的领域是计算机和安全方面，应该会有自己的一些独到的见解，所以，就让我们走进这位大神的辩论吧！

2.2 论点

咱们了解了作者的背景资料后，回到今天的正题，来看看这场辩论的论点：

结论摘要:

iPhone 的安全保障主要由 iPhone 的操作系统（iOS）执行
有证据表明，应用审核(App Review)的流程在强制额外的安全属性方面做的很弱，这些属性不能单独由操作系统强制执行（笔者注：这里的意思是指，苹果的审核其实对安全性方面审查很弱鸡！？）
iOS 和 macOS 很像，已经能够安装不是通过苹果应用商店(App Store)分发的应用程序
如果苹果允许 iPhone 用户选择第三方应用分发渠道，那么这些用户也不会遭受安全性显着降低的体验

针对这些‮点论‬，咱们不要着急辩解，接下来，先听听教授是怎么展开辩论啊~

2.3 论据：如何在 iPhone 上实施安全措施？

从图中可以看到，在 iPhone 上的安全防护分了三层：

设备外部安全(OFF-DEVICE SECURITY)：应用发分。（Can be performed by third parties（可以由第三方执行））
设备内部安全(ON-DEVICE SECURIY)：操作系统。（Independent of app distribution method（独立于应用程序分发方法））
设备内部安全(OFF-DEVICE SECURITY)：硬件

**设备外部安全(OFF-DEVICE SECURITY)**，分为：

App Review（应用审核）
Developer Identification（开发者身份识别）
Code Signing（代码签名）

这些方式，相对于 iOS 设备上的安全性机制提供的最低限度安全性（如果有的话）（Provides minimal (if any) security benefits relative to what iOS on-device security mechanisms provide）。

笔者注：这里教授意思是，这部分的安全防护收益最少，言下之意是说，App Review（应用审核）对安全性防护作用很少！？

这里其实就是本次辩论的主题，Epic Games 希望苹果降低 AppStore 内购分成，最直接的方式，直接不走苹果应用审核，这样就完美啦！所以 Epic Games 找到了安全性的角度：从 iOS 安全性来说，应用审核的作用很小，所以，应用分发可以不通过苹果审核！？

明白了 Epic Games 的需求，我们就可以猜到，James Mickens 教授接下来就是要证明，iOS 的安全性是如何防御的，思路很重要，我们接着继续吃瓜！

设备内部安全(ON-DEVICE SECURIY)：（操作系统），分为：

Digital Signature Validation（数字签名验证）
Sandboxing（沙盒机制）
Address Space Layout Randomization (ASLR)（地址空间布局随机化）
Execute Never (W^X)（永不执行，W^X：要么写，要么执行，但不能同时可写可执行）
Memory Isolation（内存隔离）
Kernel Integrity Protection（内核完整性保护）
Page Protection Layer（内存页保护层）

设备内部安全(ON-DEVICE SECURIY)：（硬件），分为：

Biometric Authentication（生物认证）
Secure Enclave（安全区域）
Storage Encryption（存储加密）
Secure Boot（安全启动）

操作系统和硬件层，接下来会展开，所以我们先说说第一层，教授认为第一层的安全防护相对第二层和第三层的作用，是最低限度（minimal），其实，就是想推翻苹果的应用审核机制~~，这个观点不重点(大家不用太纠结)，我们要关注的重点是教授是如何论证，这才是吃瓜重点哦~~

2.4 操作系统设计

教授真的太用心了！为了方便吃瓜群众理解（法官？），就是刚刚说的第二和第三层，不是学计算机技术的同学，可能不太能理解，所以教授先穿插了一个对比图：

从图上可以看到，教授把餐厅和计算设备(计算机，iPhone也是微型计算机)做对比，也就是说，大家可以把 iPhone 理解成一个“餐厅”。

食客 -> App
服务员 -> 中间件
厨师 -> 内核
厨房-> 硬件

一个餐厅的核心是什么？当然是厨师和服务员啊！所以这部分就是相当于操作系统，也就是 iOS 系统，iPhone 的核心。

大家应该能能理解吧，感觉有点道理~ 所以，教授又开始论述 iOS 操作系统：

2.5 论据：如何在 iPhone 上实施安全措施？（操作系统）

Kernel Integrity Protection（内核完整性保护）
Page Protection Layer（内存页保护层）

这2个特性是内核内存保护，这里暂时也不作过多介绍，后续如果有时间笔者在独立写篇文章展开说说吧。大家有兴趣也可以自行搜索一下啊~

Address Space Layout Randomization (ASLR)（地址空间布局随机化）
Execute Never (W^X)（永不执行，W^X：要么写，要么执行，但不能同时可写可执行）
Memory Isolation（内存隔离）

这3个特性，是用在内核和 App 之间的内存保护。下文会详细介绍，这里先略过啊。

Sandboxing（沙盒机制）

沙盒是一种安全机制，用于防止不同应用之间互相访问。iOS系统下每个应用都有自己对应的沙盒，每个沙盒之间都是相互独立的，互不能访问（没有越狱的情况下）。

每个应用程序都有自己的存储空间；
应用程序不能越过自己的空间去访问不属于自己的空间资源；
应用程序请求的数据都要通过权限检测，假如不符合条件的话，不能获取到。

沙盒机制，这个不用多说大家都知道，iOS 沙盒：每个 App 单独的资源，不单单是说存储空间，还包括进程调度等，iOS 系统会隔离行为异常的进程，保证 App 之间相互隔离，确保每个 App 的安全性。

Digital Signature Validation（数字签名验证）

这个好理解，就是启动 App 时，都会检查包体里的开发者证书，检查代码签名，授权各种App分发模型（也就是不同类型的授权证书，个人、公司、企业等签名的证书）。

综上，这些操作系统(iOS)的特性，是独立于App分发的安全防护方法。

笔者注：App分发，这里重点是指苹果的应用审核，也就是说，iOS 系统本身自带的安全特性，是不依赖 App分发渠道，更加不依赖苹果应用审核。

2.6 iOS 应用审核：安全属性

从上图可以看出，教授是通过几个安全属性，对比苹果应用审核和 iOS 系统设备，从以下几个方面进行对比：

Sandbox Compliance（沙箱合规性）
Exploit Resistance（防御抵抗）
Malware Exclusion（恶意软件排除）
User Consent for Private Data（用户同意的私人数据）
Legal Compliance（合法合规）

前三点，应用审核和 iOS 系统都能够做到，所以，我们就看看不同的点，“User Consent for Private Data（用户同意的私人数据）”，这个苹果审核确实是很难检查，教授说：“weak, at best”(弱，充其量)，而 iOS 系统，教授认为通过监听系统API调用，可以做到安全防护，感觉也还行？但好像都无法完全避免用户的私人数据不被收集和利用啊。

最后的 “Legal Compliance（合法合规）”，教授认为：“通过苹果审核或者 iOS 系统，都很难确定”。客观来说，其实人工审核还是可以避免一些问题的（比如版权问题），所以教授的这个观点有点站不稳脚啊~ 当然，应用过审后更改应用内容，这个也是应用审核无法避免的问题，如果是这个，那就与教授说的结论一致啊，这个就仁者见仁啦~

最后总结一下 iOS 系统的安全特性 苹果的安全性，如果大家了解过越狱，或者 iOS 系统底层，一定会看到过的Sandboxing、ASLR、W^X、KIP 这些名词，所以，笔者为大家总结这些名词的含义（如果觉得不错，就给我们点赞吧！）：

名词	解析	备注
`SIP`	System Integrity Protection，系统完整性保护	OS X El Capitan（2015年9月16日）中引入的Apple macOS操作系统的一项安全功能。它包含许多由内核执行的机制。核心是保护系统拥有的文件和目录，以防止没有特定“权限”的进程修改，即使由root用户或具有root特权的用户执行也是如此。
`AMFI`	Apple Mobile File Integration，苹果手机文件完整性	起源于iOS，它阻止了任何运行未签名代码的尝试。AMFI是内核扩展，最初在iOS中引入。在macOS 10.10 添加到macOS中。就像沙盒一样，它扩展了 MACF（强制性访问控制框架），并且在执行SIP和代码签名方面起着关键作用。
`MACF`	MAC (Mandatory Access Control) Framework，强制访问控制架构	在 Mac OS X 10.5 Leopard（2007年10月26日）的 SDK 中苹果“错误的”为大家引入了一种新的监控机制 —— Mandatory Access Control Policy Framework。很快苹果公司纠正了这一错误，彻底将这一接口私有化。在文档 QA1574 中苹果明确的指出第三方不应该使用 MAC 机制，它不属于 KPI 的一部分。MACF 是苹果从 TrustedBSD 引入的一项强大的安全特性。用户态的视角非常有局限性，只有内核才能可靠地实施这种安全性。当XNU 调用MAC层验证一个操作时，MAC层调用策略模块，然后策略模块负责进行验证。
`PIC` / `PIE`	Position Independent Code，地址无关代码。又称 `PIE`， Position Independent Executables，地址无关可执行文件	在计算机领域中，地址无关代码，又称地址无关可执行文件，是指可在主存储器中任意位置正确地运行，而不受其绝对地址影响的一种机器码。PIC广泛使用于共享库，使得同一个库中的代码能够被加载到不同进程的地址空间中。PIC还用于缺少内存管理单元的计算机系统中，使得操作系统能够在单一的地址空间中将不同的运行程序隔离开来。
`ASLR`	Address Space Layout Randomization，地址空间布局随机化	这项技术是在 OS X Mountain Lion（2012年7月25日）引入的。现在已经成为操作系统想要阻止黑客和恶意软件视图注入代码攻击的必备技术。防御代码注入的主要方法是数据执行阻止(Data Execution Prevention，DEP，在Intel 中也称为W^X或XD，在ARM中也称为XN)，DEP能使得黑客注入代码的企图更加困难。
`W^X`	Write XOR execute	苹果芯片会强制内存页面的属性要么可以写，要么可以执行，但不能同时为可以写可执行。特别是像JS那种带有JIT功能语言，经常会分配可写可执行的内存页面，苹果因此提供了一个专门的API（pthread_jit_write_protect_np()）用于JIT来做RW和RX内存页面之间的转换。
`KPP`	Kernel Patch Protection 内核完整性保护	与iOS9一起推出的内核完整性保护又称为“KPP”，防止运行时内核被篡改。当内核载入内存以后，苹果芯片会保护内核的内存页面，以防止其被篡改。
`PAC`	指针验证	指针验证是利用arm架构的特性，在PC进行跳转的时候对指针进行验证，从而可以有效地防止像ROP（返回导向编程）这样的攻击。苹果在iPhone XS和XR中首次部署了这个机制。目前苹果只是对macOS的内核和系统服务做了PAC的防护，我们自己在Mac上编写的app并没有PAC的防护。
`Device isolation`	设备内存隔离	在intel架构的Mac上，系统上的设备和驱动的内存空间是共享的，但是在arm64架构的Mac上，不同设备和驱动之间的内存是相互隔离的。
`Secure boot`	安全启动	新架构 Apple Silicon 的 Mac 设备 macOS Big Sur 的启动使用了iOS的安全启动模式，苹果芯片会验证每一步加载的固件的签名，以保证其完整性和安全性。同时，在系统安装的时候，用户可以选择是`full security`（完整安全）模式还是 `reduce security`（低安全）模式。苹果默认会采用完整安全模式，在完整安全模式下，可以认为这台mac和一台iPhone一样，比如无法降级，无法加载第三方的内核扩展。在低安全模式下，用户可以安装任意版本的macOS以及加载内核扩展，关闭SIP（系统完整性保护）等。
`AFC`	Apple File Conduit，苹果文件连接	运行在iOS设备上的文件传送服务，它允许你通过USB连线存取iPhone的 `/var/mobile/Media` 的目录里的文件。AFC 服务由 `lockdownd` 守护进程提供，被命名为 `com.apple.afc`。

2.7 iOS App 分发模型：安全特性

教授了为强调 App Review 审核，总结了目前 iOS App 分发的方式：

App Store
企业证书签名
TestFlight 测试

从图中可以看到，教授是想表达，App Review 这个流程有没有，好像不影响？？

笔者注：有2点需要指出纠正，第一点是 TestFlight 测试如果要对外开放，是需要人工审核的，详细见官方文档：TestFlight - Apple Developer。第二点，除了以上分发方式，国内还出现一种叫“超级签名”的分发方式，详细可以看这篇文章：说说 iOS 非 AppStore 安装App的方法。

2.8 macOS：App 分发模型

说了这么多，教授话锋一转，终于回到辩题上啦！iOS vs macOS 系统对比，所以开始讲解 macOS 系统目前分发 App 的方式：

Mac App Store
第三方分发（公证）
第三方分发（不审核+不公证）

笔者注：Notarization(公证)，从 macOS 10.15 起，所有从互联网下载的未进行 Notarization(公证) 的 App，默认将无法被打开，所以在 App Store 外分发的 App，必须在发布前将 App 上传到苹果的服务器进行处理。公证就是要把包通过指令发送到苹果服务器进行验证(有没有病毒什么的)，然后通过后，苹果会返回验证后的包体，这个包体就可以分发给别人安装。更多公证的资料，可以查看苹果官方资料：All About Notarization - WWDC 2019 - Videos - Apple Developer。

2.9 对比 iOS 和 macOS 的软件层

从图中可以看到，iOS 和 macOS 的核心系统都是共享，而中间件会有各自特殊的处理。也就是说，在操作系统底层，iOS 和 macOS 的安全机制非常的相似。

笔者注：苹果从去年 WWDC20 推出 macOS 11 Big Sur 和 ARM 架构的 Apple Silicon M1 芯片后，其实 M1 设备的系统引导启动流程，就是直接搬 iPhone 的流程，因为大家都是 ARM 架构，而且 iPhone 上的设计已经非常完善，所以，在系统底层上，iPhone 和 M1(macOS Big Sur) 确实是非常的相似了，详细可以看看 WWDC20 视频：Explore the new system architecture of Apple silicon Macs - WWDC 2020 - Videos - Apple Developer。

2.10 如何在 iOS 和 macOS 上实施安全性？

最后，教授通过比如 iOS 和 macOS 之间安全性的相同点和差异点，给出了结论，在 iOS 上实践 macOS 的安全性的三个技术点：

Notarization (公证)
Catekeeper（门禁，看门人）
Malware Scanners（恶意软件扫描器）

笔者注：Gatekeeper 可保证用户安装来自Mac App Store或者拥有开发者签名的应用。具体来说，它可以作为 Mac App Store 的应用鉴别工具，也可识别来自 Mac App Store 以外应用的开发者身份，从而防止一些恶意软件的进入。参考官方资料：Advances in macOS Security - WWDC 2019 - Videos - Apple Developer、Safely open apps on your Mac - Apple Support、在 macOS 部署中使用门禁 - Apple 支持。

到此，教授的意图很明确了！

“iOS 本可以和 macOS 一样开放，不‮安受‬全性影响”

如果在 iOS 系统增加以上3个 macOS 的安全特性，那么 iOS App 的安全防护应该可以得到进一步的提升，iPhone 的安全也得到了进一步的保障。当然，教授的这一切论证都是从技术安全性来考虑，如果是从人性安全角度呢？

所以，大家怎么看这个问题，欢迎在评论区一起讨论啊~

2.11 App 分发：设计含义

最后，教授给了一张 iOS 和 macOS 对比图，到此，辩论结束~

这张总结的图片，是想表达，在 iOS 和 macOS 的 App 分发中，操作系统已经做了安全性保障，而苹果应用审核只是保证了 App Store 渠道和 Notarized(公证，主要作用是扫描恶意软件病毒的功能。)，而其它的分发方式，比如开发者企业证书、TestFlight、Mac 未认证的第三方 App 等渠道，其实也没有苹果应用审核，但是目前也没有安全性问题？？？

所以，苹果是不是可以让第三方的分发渠道更开放？？？

三、总结

大家可以看得出来，教授的整个论证过程非常的有意思，而且我们从中可以学到很多 iOS 的知识，真的是吃瓜又涨知识！

教授说的 iOS 增加 Notarization (公证)、Catekeeper（门禁，看门人）、Malware Scanners（恶意软件扫描器）后安全性与 macOS 相当，而 macOS 并没有大的安全问题，所以像 macOS 一样开放 iOS 系统，而不需要应用审核，好像也是非常合理！？当然，James Mickens 教授的证词是为了捍卫 Epic Games 反对 iOS 应用商店的一个核心论证。大家可以保持自己的观点和思考，不必完成接受啊。

笔者认为，从安全技术上，教授的思考角度非常有道理，从技术安全性来说，我们要提升安全性，就是从攻防着手，还有就是借鉴优秀的设计（比如 macOS），确实是值得 iOS 借鉴。

至于，iOS 人工审核的机制或者 App Store 机制，就没有办法一两句话能说清楚的，所以我们打算在下一篇文章，谈谈苹果应用审核的相关内幕资料，敬请期待~

今天吃瓜就到这里，大家有任何问题，欢迎在评论区一起交流啊~