| RFC-0118：映像檔組件上的 SWD 政策 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 短期變更：在圖像組裝時套用 SWD 政策。 |
| 問題 | |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-06-28 |
| 審查日期 (年-月-日) | 2021-07-28 |
摘要
此 RFC 提議了一個權宜之路，讓您可以獲得更好的可視性、理解，並 能充分提高軟體推送 (SWD) 政策設定的擴充性 制定政策的適用範圍，讓任何開發人員都能瞭解 該軟體可以在搭載 Fuchsia 的裝置上執行，而且能確保 才能順利運送不安全的設定。
目前的提案應處於現有形式，直到 子組裝式產品組裝可提供更明確的政策 適合不同產品用途本提案的中介效果 可讓您輕鬆轉換至系統組合樣式設定， 集中實施 SWD 政策的工作 完成。
提振精神
在強制執行經過驗證的執行作業時，SWD 設定是不可或缺的一環。目前， SWD 設定會拆分為 藉此確認機器上的實際 SWD 設定 裝置。此 RFC 旨在降低瞭解 SWD 狀態的複雜度 。嚴格理解並審慎運用政策 新產品和子類變得更簡單安全， 確認套用正確設定
設計
目前我們根據此 RFC 提議採用三項 SWD 政策。目的是 使用語意 (而非 以產品為準的命名方式這些政策適用於產品定義 更全面地定義 SWD 狀態 產品擁有者 會選取其中一個 而不是逐一調整每項配置設定
如有需要，我們或許會新增更多政策，但您預期可採行這組政策 遠小於產品和建構變化版本的成長空間
政策定義
僅限基礎元件
所有可執行的程式碼都必須直接驗證 (基底)。所有可設定的 SWD 限制已設為預設安全狀態：動態設定 系統不允許存放庫，且可執行性限制 只有基礎元件和許可清單中的元件才能解析並執行。
本機動態設定
允許存放區的動態設定和手動解析度 間接驗證程式碼 (反向套件/臨時元件)，且 使用者能否實際存取 (例如開發人員)。
無限制
對於雲端系統的可執行性或可見性沒有任何限制， 再也不是件繁重乏味的工作這是允許的 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，這項提案會修改相應的群組目標
加入根據基礎目錄定義的 GN 群組
policy_labels 建構引數，這是可儲存一組
圖片組合方式解讀的鍵/值組合 (本例中為 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) 和 config-data 套件 (適用於
enable_dynamic_configuration 和 persisted_repos_dir)。
變更。
說明文件
會新增其他文件，說明 SWD 政策設定。
缺點、替代方案和未知
本次異動旨在提供短期的解決方案，直到平台實施為止 可讓我們更精細地控管 建構程序這項作業是以進行中的 RFCS 形式擷取，用於子組件 (fxr/553664) 和結構化設定 (fxr/549661)。
這項變更的重點是這項抽象化套件/依附元件 納入產品定義中
經過調查的替代方案如下：
沒有進行任何變更
我們會繼續居住在目前環境，每款產品 也會繼續沿用每項產品 那可能來自於祖先的聯集。
然而，隨著 Fuchsia 產品日益增加，我們將這項提案 主動改善 SWD 設定機制， 避開將錯誤的 SWD 狀態套用至可能的事件 顛覆了 Fuchsia 平台的核心安全假設。
修改產品定義
這與目前的流程類似，但 對 YAML 檔案 我們會定義各層級的設定我們判定是 這簡直是不可能的任務 也無法擴充至持續增加的產品組合這也 強調了 必須變更所有子項層級，才能設定或重設樹狀結構 相關的元件
在建構驗證時斷言
我們可以卸載判斷建構作業是否使用 正確設定以建構驗證，確保 依附元件與每個版本相關聯這可以解決 確定建構的映像檔具有正確設定，但無法解決 還是無法改善人體工學 瞭解指定設定中的 SWD 堆疊行為。
修改/減少 SWD 配置設定
我們調查過無法修改 SWD 邏輯 ，減少設定數量，然後降至單一值。 不幸的是，由於在實作 SWD 堆疊的情況下，這種做法並不適用 建立多個元件 並分散在各處