論證：iOS安全性，為什么需要審核？
轉(zhuǎn)自：掘金 37手游ios技術(shù)運營團隊
https://juejin.cn/post/6967199105541996575
一、前言
最近，Epic Games vs Apple 的訴訟大戰(zhàn)非常的激烈精彩，報料的內(nèi)幕消息也十分勁爆！滿足了一波炎炎夏日的吃瓜群眾，當然作為技術(shù)人員，我們除了關(guān)注瓜甜不甜，還要分析這瓜為什么甜？
Epic Games 邀請了一位專家證人，針對“iOS安全性”這個問題進行展開辯論，即：蘋果可以讓 iOS 系統(tǒng)，在應(yīng)用分發(fā)和第三方訪問等方面更像 macOS，也不會在安全性方面受到影響。
二、正文
2.1 辯論者
針對這個辯題：“iOS 本可以和 macOS 一樣開放，不?安受?全性影響”（iOS could be like macOS without security drawbacks），我們先來看看辯論者，Epic Games 的專家證人，哈佛?學大?計算機科學教授 James Mickens，這是何許人也？
大家對 James Mickens 教授可能不太了解，沒有關(guān)系！我們可以通過維基百科 一起來看看：
James W. Mickens 是美國計算機科學家，是哈佛大學約翰·A·保爾森工程與應(yīng)用科學學院的 Gordon McKay 計算機科學教授。他的研究重點是分布式系統(tǒng)，例如大規(guī)模服務(wù)以及使它們更安全的方法。他對將機器學習作為解決最突出的計算問題的樣板解決方案持批評態(tài)度。
另外，八卦一下，“Gordon McKay” 這個頭銜：戈登·麥凱（Gordon McKay）是一位富有的商人，他向哈佛捐贈了一大筆錢，這筆錢被存入了一個信托基金。該基金的資金用于支付哈佛的40個不同的教授職位。擁有戈登·麥凱授予的椅子的人——即受雇于哈佛大學教授的人，其職位由戈登·麥凱設(shè)立的信托基金資助——將擁有“戈登·麥凱教授”的頭銜。引用來源：What is a 'Gordon McKay Professor'? - Quora
針對辯論者 James Mickens 教授的介紹，大家可以知道，他關(guān)注的領(lǐng)域是計算機和安全方面，應(yīng)該會有自己的一些獨到的見解，所以，就讓我們走進這位大神的辯論吧！
2.2 論點
咱們了解了作者的背景資料后，回到今天的正題，來看看這場辯論的論點：
結(jié)論摘要:
iPhone 的安全保障主要由 iPhone 的操作系統(tǒng)（iOS）執(zhí)行 有證據(jù)表明，應(yīng)用審核(App Review)的流程在強制額外的安全屬性方面做的很弱，這些屬性不能單獨由操作系統(tǒng)強制執(zhí)行（ 筆者注：這里的意思是指，蘋果的審核其實對安全性方面審查很弱雞！？）iOS 和 macOS 很像，已經(jīng)能夠安裝不是通過蘋果應(yīng)用商店(App Store)分發(fā)的應(yīng)用程序 如果蘋果允許 iPhone 用戶選擇第三方應(yīng)用分發(fā)渠道，那么這些用戶也不會遭受安全性顯著降低的體驗
針對這些?點論?，咱們不要著急辯解，接下來，先聽聽教授是怎么展開辯論啊~
2.3 論據(jù)：如何在 iPhone 上實施安全措施？
從圖中可以看到，在 iPhone 上的安全防護分了三層：
設(shè)備外部安全(OFF-DEVICE SECURITY)：應(yīng)用發(fā)分。（Can be performed by third parties（可以由第三方執(zhí)行）） 設(shè)備內(nèi)部安全(ON-DEVICE SECURIY)：操作系統(tǒng)。（Independent of app distribution method（獨立于應(yīng)用程序分發(fā)方法）） 設(shè)備內(nèi)部安全(OFF-DEVICE SECURITY)：硬件
設(shè)備外部安全(OFF-DEVICE SECURITY)，分為：
App Review（應(yīng)用審核） Developer Identification（開發(fā)者身份識別） Code Signing（代碼簽名）
這些方式，相對于 iOS 設(shè)備上的安全性機制提供的最低限度安全性（如果有的話）（Provides minimal (if any) security benefits relative to what iOS on-device security mechanisms provide）。
筆者注：這里教授意思是，這部分的安全防護收益最少，言下之意是說，App Review（應(yīng)用審核）對安全性防護作用很少！？
這里其實就是本次辯論的主題，Epic Games 希望蘋果降低 AppStore 內(nèi)購分成，最直接的方式，直接不走蘋果應(yīng)用審核，這樣就完美啦！所以 Epic Games 找到了安全性的角度：從 iOS 安全性來說，應(yīng)用審核的作用很小，所以，應(yīng)用分發(fā)可以不通過蘋果審核！？
明白了 Epic Games 的需求，我們就可以猜到，James Mickens 教授接下來就是要證明，iOS 的安全性是如何防御的，思路很重要，我們接著繼續(xù)吃瓜！
設(shè)備內(nèi)部安全(ON-DEVICE SECURIY)：（操作系統(tǒng)），分為：
Digital Signature Validation（數(shù)字簽名驗證） Sandboxing（沙盒機制） Address Space Layout Randomization (ASLR)（地址空間布局隨機化） Execute Never (W^X)（永不執(zhí)行， W^X：要么寫，要么執(zhí)行，但不能同時可寫可執(zhí)行）Memory Isolation（內(nèi)存隔離） Kernel Integrity Protection（內(nèi)核完整性保護） Page Protection Layer（內(nèi)存頁保護層）
設(shè)備內(nèi)部安全(ON-DEVICE SECURIY)：（硬件），分為：
Biometric Authentication（生物認證） Secure Enclave（安全區(qū)域） Storage Encryption（存儲加密） Secure Boot（安全啟動）
操作系統(tǒng)和硬件層，接下來會展開，所以我們先說說第一層，教授認為第一層的安全防護相對第二層和第三層的作用，是最低限度（minimal），其實，就是想推翻蘋果的應(yīng)用審核機制~，這個觀點不重點(大家不用太糾結(jié))，我們要關(guān)注的重點是教授是如何論證，這才是吃瓜重點哦~
2.4 操作系統(tǒng)設(shè)計
教授真的太用心了！為了方便吃瓜群眾理解（法官？），就是剛剛說的第二和第三層，不是學計算機技術(shù)的同學，可能不太能理解，所以教授先穿插了一個對比圖：
從圖上可以看到，教授把餐廳和計算設(shè)備(計算機，iPhone也是微型計算機)做對比，也就是說，大家可以把 iPhone 理解成一個“餐廳”。
食客 -> App 服務(wù)員 -> 中間件 廚師 -> 內(nèi)核 廚房-> 硬件
一個餐廳的核心是什么？當然是廚師和服務(wù)員啊！所以這部分就是相當于操作系統(tǒng)，也就是 iOS 系統(tǒng)，iPhone 的核心。
大家應(yīng)該能能理解吧，感覺有點道理~ 所以，教授又開始論述 iOS 操作系統(tǒng)：
2.5 論據(jù)：如何在 iPhone 上實施安全措施？（操作系統(tǒng)）
Kernel Integrity Protection（內(nèi)核完整性保護） Page Protection Layer（內(nèi)存頁保護層）
這2個特性是內(nèi)核內(nèi)存保護，這里暫時也不作過多介紹，后續(xù)如果有時間筆者在獨立寫篇文章展開說說吧。大家有興趣也可以自行搜索一下啊~
Address Space Layout Randomization (ASLR)（地址空間布局隨機化） Execute Never (W^X)（永不執(zhí)行， W^X：要么寫，要么執(zhí)行，但不能同時可寫可執(zhí)行）Memory Isolation（內(nèi)存隔離）
這3個特性，是用在內(nèi)核和 App 之間的內(nèi)存保護。下文會詳細介紹，這里先略過啊。
Sandboxing（沙盒機制）
沙盒是一種安全機制，用于防止不同應(yīng)用之間互相訪問。iOS系統(tǒng)下每個應(yīng)用都有自己對應(yīng)的沙盒，每個沙盒之間都是相互獨立的，互不能訪問（沒有越獄的情況下）。
每個應(yīng)用程序都有自己的存儲空間； 應(yīng)用程序不能越過自己的空間去訪問不屬于自己的空間資源； 應(yīng)用程序請求的數(shù)據(jù)都要通過權(quán)限檢測，假如不符合條件的話，不能獲取到。
沙盒機制，這個不用多說大家都知道，iOS 沙盒：每個 App 單獨的資源，不單單是說存儲空間，還包括進程調(diào)度等，iOS 系統(tǒng)會隔離行為異常的進程，保證 App 之間相互隔離，確保每個 App 的安全性。
Digital Signature Validation（數(shù)字簽名驗證）
這個好理解，就是啟動 App 時，都會檢查包體里的開發(fā)者證書，檢查代碼簽名，授權(quán)各種App分發(fā)模型（也就是不同類型的授權(quán)證書，個人、公司、企業(yè)等簽名的證書）。
綜上，這些操作系統(tǒng)(iOS)的特性，是獨立于App分發(fā)的安全防護方法。
筆者注：App分發(fā)，這里重點是指蘋果的應(yīng)用審核，也就是說，iOS 系統(tǒng)本身自帶的安全特性，是不依賴 App分發(fā)渠道，更加不依賴蘋果應(yīng)用審核。
2.6 iOS 應(yīng)用審核：安全屬性
從上圖可以看出，教授是通過幾個安全屬性，對比蘋果應(yīng)用審核和 iOS 系統(tǒng)設(shè)備，從以下幾個方面進行對比：
Sandbox Compliance（沙箱合規(guī)性） Exploit Resistance（防御抵抗） Malware Exclusion（惡意軟件排除） User Consent for Private Data（用戶同意的私人數(shù)據(jù)） Legal Compliance（合法合規(guī)）
前三點，應(yīng)用審核和 iOS 系統(tǒng)都能夠做到，所以，我們就看看不同的點，“User Consent for Private Data（用戶同意的私人數(shù)據(jù)）”，這個蘋果審核確實是很難檢查，教授說：“weak, at best”(弱，充其量)，而 iOS 系統(tǒng)，教授認為通過監(jiān)聽系統(tǒng)API調(diào)用，可以做到安全防護，感覺也還行？但好像都無法完全避免用戶的私人數(shù)據(jù)不被收集和利用啊。
最后的 “Legal Compliance（合法合規(guī)）”，教授認為：“通過蘋果審核或者 iOS 系統(tǒng)，都很難確定”。客觀來說，其實人工審核還是可以避免一些問題的（比如版權(quán)問題），所以教授的這個觀點有點站不穩(wěn)腳啊~ 當然，應(yīng)用過審后更改應(yīng)用內(nèi)容，這個也是應(yīng)用審核無法避免的問題，如果是這個，那就與教授說的結(jié)論一致啊，這個就仁者見仁啦~
最后總結(jié)一下 iOS 系統(tǒng)的安全特性 蘋果的安全性，如果大家了解過越獄，或者 iOS 系統(tǒng)底層，一定會看到過的Sandboxing、ASLR、W^X、KIP 這些名詞，所以，筆者為大家總結(jié)這些名詞的含義（如果覺得不錯，就給我們點贊吧！）：
| 名詞 | 解析 | 備注 |
|---|---|---|
SIP | System Integrity Protection，系統(tǒng)完整性保護 | OS X El Capitan（2015年9月16日）中引入的Apple macOS操作系統(tǒng)的一項安全功能。它包含許多由內(nèi)核執(zhí)行的機制。核心是保護系統(tǒng)擁有的文件和目錄，以防止沒有特定“權(quán)限”的進程修改，即使由root用戶或具有root特權(quán)的用戶執(zhí)行也是如此。 |
AMFI | Apple Mobile File Integration，蘋果手機文件完整性 | 起源于iOS，它阻止了任何運行未簽名代碼的嘗試。AMFI是內(nèi)核擴展，最初在iOS中引入。在macOS 10.10 添加到macOS中。就像沙盒一樣，它擴展了 MACF（強制性訪問控制框架），并且在執(zhí)行SIP和代碼簽名方面起著關(guān)鍵作用。 |
MACF | MAC (Mandatory Access Control) Framework，強制訪問控制架構(gòu) | 在 Mac OS X 10.5 Leopard（2007年10月26日） 的 SDK 中蘋果“錯誤的”為大家引入了一種新的監(jiān)控機制 —— Mandatory Access Control Policy Framework。很快蘋果公司糾正了這一錯誤，徹底將這一接口私有化。在文檔 QA1574 中蘋果明確的指出第三方不應(yīng)該使用 MAC 機制，它不屬于 KPI 的一部分。MACF 是蘋果從 TrustedBSD 引入的一項強大的安全特性。用戶態(tài)的視角非常有局限性，只有內(nèi)核才能可靠地實施這種安全性。當XNU 調(diào)用MAC層驗證一個操作時，MAC層調(diào)用策略模塊，然后策略模塊負責進行驗證。 |
PIC / PIE | Position Independent Code，地址無關(guān)代碼。又稱 PIE， Position Independent Executables，地址無關(guān)可執(zhí)行文件 | 在計算機領(lǐng)域中，地址無關(guān)代碼，又稱地址無關(guān)可執(zhí)行文件，是指可在主存儲器中任意位置正確地運行，而不受其絕對地址影響的一種機器碼。PIC廣泛使用于共享庫，使得同一個庫中的代碼能夠被加載到不同進程的地址空間中。PIC還用于缺少內(nèi)存管理單元的計算機系統(tǒng)中， 使得操作系統(tǒng)能夠在單一的地址空間中將不同的運行程序隔離開來。 |
ASLR | Address Space Layout Randomization，地址空間布局隨機化 | 這項技術(shù)是在 OS X Mountain Lion（2012年7月25日） 引入的。現(xiàn)在已經(jīng)成為操作系統(tǒng)想要阻止黑客和惡意軟件視圖注入代碼攻擊的必備技術(shù)。防御代碼注入的主要方法是數(shù)據(jù)執(zhí)行阻止(Data Execution Prevention，DEP，在Intel 中也稱為W^X或XD，在ARM中也稱為XN)，DEP能使得黑客注入代碼的企圖更加困難。 |
W^X | Write XOR execute | 蘋果芯片會強制內(nèi)存頁面的屬性要么可以寫，要么可以執(zhí)行，但不能同時為可以寫可執(zhí)行。特別是像JS那種帶有JIT功能語言，經(jīng)常會分配可寫可執(zhí)行的內(nèi)存頁面，蘋果因此提供了一個專門的API（pthread_jit_write_protect_np()）用于JIT來做RW和RX內(nèi)存頁面之間的轉(zhuǎn)換。 |
KPP | Kernel Patch Protection 內(nèi)核完整性保護 | 與iOS9一起推出的內(nèi)核完整性保護又稱為“KPP”，防止運行時內(nèi)核被篡改。當內(nèi)核載入內(nèi)存以后，蘋果芯片會保護內(nèi)核的內(nèi)存頁面，以防止其被篡改。 |
PAC | 指針驗證 | 指針驗證是利用arm架構(gòu)的特性，在PC進行跳轉(zhuǎn)的時候?qū)χ羔樳M行驗證，從而可以有效地防止像ROP（返回導向編程）這樣的攻擊。蘋果在iPhone XS和XR中首次部署了這個機制。目前蘋果只是對macOS的內(nèi)核和系統(tǒng)服務(wù)做了PAC的防護，我們自己在Mac上編寫的app并沒有PAC的防護。 |
Device isolation | 設(shè)備內(nèi)存隔離 | 在intel架構(gòu)的Mac上，系統(tǒng)上的設(shè)備和驅(qū)動的內(nèi)存空間是共享的，但是在arm64架構(gòu)的Mac上，不同設(shè)備和驅(qū)動之間的內(nèi)存是相互隔離的。 |
Secure boot | 安全啟動 | 新架構(gòu) Apple Silicon 的 Mac 設(shè)備 macOS Big Sur 的啟動使用了iOS的安全啟動模式，蘋果芯片會驗證每一步加載的固件的簽名，以保證其完整性和安全性。同時，在系統(tǒng)安裝的時候，用戶可以選擇是full security（完整安全）模式還是 reduce security（低安全）模式。蘋果默認會采用完整安全模式，在完整安全模式下，可以認為這臺mac和一臺iPhone一樣，比如無法降級，無法加載第三方的內(nèi)核擴展。在低安全模式下，用戶可以安裝任意版本的macOS以及加載內(nèi)核擴展，關(guān)閉SIP（系統(tǒng)完整性保護）等。 |
AFC | Apple File Conduit，蘋果文件連接 | 運行在iOS設(shè)備上的文件傳送服務(wù)，它允許你通過USB連線存取iPhone的 /var/mobile/Media 的目錄里的文件。AFC 服務(wù)由 lockdownd 守護進程提供，被命名為 com.apple.afc。 |
2.7 iOS App 分發(fā)模型：安全特性
教授了為強調(diào) App Review 審核，總結(jié)了目前 iOS App 分發(fā)的方式：
App Store 企業(yè)證書簽名 TestFlight 測試
從圖中可以看到，教授是想表達，App Review 這個流程有沒有，好像不影響？？
筆者注：有2點需要指出糾正，第一點是 TestFlight 測試如果要對外開放，是需要人工審核的，詳細見官方文檔：TestFlight - Apple Developer。第二點，除了以上分發(fā)方式，國內(nèi)還出現(xiàn)一種叫“超級簽名”的分發(fā)方式，詳細可以看這篇文章：說說 iOS 非 AppStore 安裝App的方法。
2.8 macOS：App 分發(fā)模型
說了這么多，教授話鋒一轉(zhuǎn)，終于回到辯題上啦！iOS vs macOS 系統(tǒng)對比，所以開始講解 macOS 系統(tǒng)目前分發(fā) App 的方式：
Mac App Store 第三方分發(fā)（公證） 第三方分發(fā)（不審核+不公證）
筆者注：Notarization(公證)，從 macOS 10.15 起，所有從互聯(lián)網(wǎng)下載的未進行 Notarization(公證) 的 App，默認將無法被打開，所以在 App Store 外分發(fā)的 App，必須在發(fā)布前將 App 上傳到蘋果的服務(wù)器進行處理。公證就是要把包通過指令發(fā)送到蘋果服務(wù)器進行驗證(有沒有病毒什么的)，然后通過后，蘋果會返回驗證后的包體，這個包體就可以分發(fā)給別人安裝。更多公證的資料，可以查看蘋果官方資料：All About Notarization - WWDC 2019 - Videos - Apple Developer。
2.9 對比 iOS 和 macOS 的軟件層
從圖中可以看到，iOS 和 macOS 的核心系統(tǒng)都是共享，而中間件會有各自特殊的處理。也就是說，在操作系統(tǒng)底層，iOS 和 macOS 的安全機制非常的相似。
筆者注：蘋果從去年 WWDC20 推出 macOS 11 Big Sur 和 ARM 架構(gòu)的 Apple Silicon M1 芯片后，其實 M1 設(shè)備的系統(tǒng)引導啟動流程，就是直接搬 iPhone 的流程，因為大家都是 ARM 架構(gòu)，而且 iPhone 上的設(shè)計已經(jīng)非常完善，所以，在系統(tǒng)底層上，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 之間安全性的相同點和差異點，給出了結(jié)論，在 iOS 上實踐 macOS 的安全性的三個技術(shù)點：
Notarization (公證) Catekeeper（門禁，看門人） Malware Scanners（惡意軟件掃描器）
筆者注：Gatekeeper 可保證用戶安裝來自Mac App Store或者擁有開發(fā)者簽名的應(yīng)用。具體來說，它可以作為 Mac App Store 的應(yīng)用鑒別工具，也可識別來自 Mac App Store 以外應(yīng)用的開發(fā)者身份，從而防止一些惡意軟件的進入。參考官方資料：Advances in macOS Security - WWDC 2019 - Videos - Apple Developer、Safely open apps on your Mac - Apple Support、在 macOS 部署中使用門禁 - Apple 支持。
到此，教授的意圖很明確了！
“iOS 本可以和 macOS 一樣開放，不?安受?全性影響”
如果在 iOS 系統(tǒng)增加以上3個 macOS 的安全特性，那么 iOS App 的安全防護應(yīng)該可以得到進一步的提升，iPhone 的安全也得到了進一步的保障。當然，教授的這一切論證都是從技術(shù)安全性來考慮，如果是從人性安全角度呢？
所以，大家怎么看這個問題，歡迎在評論區(qū)一起討論啊~
2.11 App 分發(fā)：設(shè)計含義
最后，教授給了一張 iOS 和 macOS 對比圖，到此，辯論結(jié)束~
這張總結(jié)的圖片，是想表達，在 iOS 和 macOS 的 App 分發(fā)中，操作系統(tǒng)已經(jīng)做了安全性保障，而蘋果應(yīng)用審核只是保證了 App Store 渠道和 Notarized(公證，主要作用是掃描惡意軟件病毒的功能。)，而其它的分發(fā)方式，比如開發(fā)者企業(yè)證書、TestFlight、Mac 未認證的 第三方 App 等渠道，其實也沒有蘋果應(yīng)用審核，但是目前也沒有安全性問題？？？
所以，蘋果是不是可以讓第三方的分發(fā)渠道更開放？？？
三、總結(jié)
大家可以看得出來，教授的整個論證過程非常的有意思，而且我們從中可以學到很多 iOS 的知識，真的是吃瓜又漲知識！
教授說的 iOS 增加 Notarization (公證)、Catekeeper（門禁，看門人）、Malware Scanners（惡意軟件掃描器）后安全性與 macOS 相當，而 macOS 并沒有大的安全問題，所以像 macOS 一樣開放 iOS 系統(tǒng)，而不需要應(yīng)用審核，好像也是非常合理！？當然，James Mickens 教授的證詞是為了捍衛(wèi) Epic Games 反對 iOS 應(yīng)用商店的一個核心論證。大家可以保持自己的觀點和思考，不必完成接受啊。
筆者認為，從安全技術(shù)上，教授的思考角度非常有道理，從技術(shù)安全性來說，我們要提升安全性，就是從攻防著手，還有就是借鑒優(yōu)秀的設(shè)計（比如 macOS），確實是值得 iOS 借鑒。
至于，iOS 人工審核的機制或者 App Store 機制，就沒有辦法一兩句話能說清楚的，所以我們打算在下一篇文章，談?wù)勌O果應(yīng)用審核的相關(guān)內(nèi)幕資料，敬請期待~
今天吃瓜就到這里，大家有任何問題，歡迎在評論區(qū)一起交流啊~
四、參考
James Mickens - Wikipedia
https://en.wikipedia.org/wiki/James_MickensWhat is a 'Gordon McKay Professor'? - Quora
https://www.quora.com/What-is-a-Gordon-McKay-ProfessorExplore the new system architecture of Apple silicon Macs - WWDC 2020 - Videos - Apple Developer
https://developer.apple.com/videos/play/wwdc2020/10686/TestFlight - Apple Developer
https://developer.apple.com/cn/testflight/說說 iOS 非 AppStore 安裝App的方法
https://juejin.cn/post/6844904050224267272All About Notarization - WWDC 2019 - Videos - Apple Developer
https://developer.apple.com/videos/play/wwdc2019/703/Safely open apps on your Mac - Apple Support
https://support.apple.com/en-us/HT202491Advances in macOS Security - WWDC 2019 - Videos - Apple Developer
https://developer.apple.com/videos/play/wwdc2019/701/在 macOS 部署中使用門禁 - Apple 支持
https://support.apple.com/zh-cn/guide/deployment-reference-macos/apd02b925e38/webEpic Games expert says iOS could be like macOS without security drawbacks | AppleInsider
https://appleinsider.com/articles/21/05/14/epic-games-expert-says-ios-could-be-like-macos-without-security-drawbacksEpic 專家：蘋果 iOS 本可以和 macOS 一樣開放，不受安全性影響 - IT之家
https://www.ithome.com/0/551/650.htm
轉(zhuǎn)自：掘金 37手游ios技術(shù)運營團隊
https://juejin.cn/post/6967199105541996575
-End-
最近有一些小伙伴，讓我?guī)兔φ乙恍?nbsp;面試題 資料，于是我翻遍了收藏的 5T 資料后，匯總整理出來，可以說是程序員面試必備！所有資料都整理到網(wǎng)盤了，歡迎下載！
面試題】即可獲取
好文分享給更多人↓↓