| RFC-0118：映像檔組件上的 SWD 政策 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 短期變更：在圖像組裝時套用 SWD 政策。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-06-28 |
| 審查日期 (年-月-日) | 2021-07-28 |
摘要
本 RFC 提出了一種暫時性解決方案，可透過定義易於理解且有範圍限制的政策，讓任何開發人員都能瞭解在搭載 Fuchsia 的裝置上，哪些軟體可以或不可以執行，並確保他們不會不小心發布安全性較低的設定。
目前的提案旨在維持目前的提案內容，直到子組合型產品組合允許針對不同產品用途明確定義政策為止。由於已完成將 SWD 政策應用集中化的工作，因此本提案中的中介作業可讓您更輕鬆地轉換至系統組合式設定。
提振精神
強制執行驗證作業時，SWD 設定是不可或缺的要素。目前，SWD 設定分成多個設定檔和套件互動，以決定裝置上實際的 SWD 設定。此 RFC 旨在降低瞭解產品 SWD 狀態的複雜度。加入經過深思熟慮的政策，也能讓新增產品和變化版本更簡單、更安全，減輕確保正確套用設定的負擔。
設計
目前，這項 RFC 提出了三項 SWD 政策。目的在於使用語意 (而非產品導向的命名) 將 SWD 政策設定正式上線。
如有需要，我們可能會新增更多政策，但這組政策應該遠低於產品和建構變化版本的成長空間。
政策定義
僅限基本元件
所有可執行的程式碼都必須直接驗證 (在基礎層)。所有可設定的 SWD 限制均會套用其預設安全狀態：系統不允許存放區的動態設定，以及執行性限制，亦即只有基礎元件和許可清單中的元件才能解析並執行。
本機動態設定
允許動態設定存放區，並手動解析間接驗證的程式碼 (Universe 套件/暫時性元件)，但前提是使用者必須有實體存取權 (例如開發人員)。
無限制
程式碼的可執行性或可見度沒有任何限制。這是最寬鬆的 SWD 設定，可允許外部程式碼和動態設定，並停用可執行性限制。
政策表
| POLICY_NAME | enable_dynamic_configuration | persisted_repos_dir | disable_executability_restrictions |
|---|---|---|---|
| base_components_only | 關閉 | 關閉 | 關閉 |
| local_dynamic_config | 開啟 | 關閉 | 關閉 |
| 無限制 | 開啟 | 開啟 | 開啟 |
實作
本 RFC 建議在圖片組合層級實作這項功能。由於 SWD 設定需要在 base_packages 和 system_image_deps 中設定值，因此提案應修改個別群組目標，納入根據 policy_labels 建構引數定義的 GN 群組的新依附元件。這個字典會儲存一組圖片組合後解讀的鍵/值組合 (本例為 swd) 及其各自的政策標籤。
這可確保為特定版本定義的 SWD 政策設定一律只有一個。
例如，假設政策定義於 //build/security/policies_swd.gni：
policies_swd = [
{
name = "local_dynamic_config"
base_package_deps = [ /* ... */ ]
system_image_deps = [ /* ... */ ]
bootfs_deps = [ /* ... */ ]
},
{
name = "foo"
// ...
},
]
產品擁有者可以在產品定義檔案中執行下列操作：
import("//build/images/policy.gni") # defines policy_labels = {} arg.
policy_labels.swd = "local_dynamic_config"
policy_labels.foo = "bar"
在圖片組件步驟中：
group("base_packages") {
testonly = base_cache_packages_testonly
visibility = [ ":*" ]
public_deps = [
// ...
]
// Addition for this proposal
deps = []
foreach (policy, policies_swd) {
if (policy.name == policy_labels.swd) {
deps += policy.base_package_deps
}
}
}
請注意，這並無法完全解決從祖系 GNI 檔案繼承產品定義的問題。不過，這麼做可簡化 SWD 政策的設定和稽核可行性。
成效
這項異動不會影響效能。
人體工學
這項變更可抽離設定，讓 SWD 設定由單一建構引數控制，進而讓您更輕鬆地瞭解及稽核裝置上的 SWD 狀態。
回溯相容性
這項變更不會影響回溯相容性，變更應以可輕鬆復原的方式進行。
安全性考量
這項變更可改善 SWD 設定狀態的簡易性、可擴充性和可讀性，而這項狀態會決定哪些軟體可以在 Fuchsia 裝置上執行。如此一來，開發人員就不太可能在出貨產品時設定不安全的設定，進而直接改善我們的安全防護機制。這樣一來，產品擁有者也能更輕鬆地進行稽核。
隱私權注意事項
這項異動不會影響隱私權，或是與使用者資料互動。
測試
我們會測試這項變更，確保變更後的版本具有預期的 SWD 政策設定。這項作業會在變更前後，手動驗證輸出建構是否有 (或沒有) 預期的檔案 (針對 disable_executability_restrictions) 和設定資料套件 (針對 enable_dynamic_configuration 和 persisted_repos_dir)。
說明文件
我們會新增其他說明文件，定義 SWD 政策設定。
缺點、替代方案和未知事項
這項變更只是暫時的解決方案，直到平台子組合存在，讓我們能更精細地控管建構程序。這項工作已納入子組件的待處理 RFCS (fxr/553664) 和結構化設定 (fxr/549661)。
這項變更的重點是，將套件/依附元件納入產品定義之外。
我們調查的替代方案如下：
沒有進行任何變更
我們可以繼續使用目前的環境，讓每項產品都能修改自己的設定，而每項產品也會繼續隨機繼承其祖系的聯合體。
不過，隨著 Fuchsia 產品的發展迅速，我們以主動對 SWD 設定機制進行改善，以避免發生產品套用不正確 SWD 狀態的事件，從而破壞了 Fuchsia 平台的核心安全性假設。
修改產品定義
這與目前的做法類似，但我們會在各個層級定義設定，而非在產品定義的繼承樹狀結構中隨機定義各種設定。我們判定這項做法不可行，因為這會讓開發人員負責瞭解每個旋鈕的功能，而且無法擴展至不斷增加的產品組合。這也帶來了額外的缺點，也就是對樹狀結構的根/祖系層級進行任何變更時，必須變更所有子層級，才能取消設定或重設相關聯的元件。
在建構驗證期間斷言
我們可以將判斷版本是否使用正確設定的問題，轉移至版本驗證，以便斷言每個版本都與正確的依附元件相關聯。這可解決確保已建構映像檔具有正確設定的問題，但無法解決可聽度/可視度問題，也無法改善在特定設定下瞭解 SWD 堆疊行為的人體工學。
修改/減少 SWD 設定
我們調查了是否能修改 SWD 邏輯，以便減少可變為單一值的設定數量。 很遺憾，這項做法不切實際，因為 SWD 堆疊是在多個套件和 zbi 的多個元件中實作，且設定分散在所有元件中。