RFC-0150：選擇不更新

RFC-0150：更新退出選項
狀態已接受
區域
  • 軟體交付
說明

產品擁有者可透過政策和功能，允許使用者選擇不接收軟體更新。
問題
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)2022-01-14
審查日期 (年-月-日)2022-01-31

編輯這份 RFC

編輯 RFC 中繼資料

摘要

我們將說明產品擁有者的新功能，讓產品使用者選擇不接收軟體更新。我們將說明與這項機制相關的政策、使用方式，以及與儲存設定相關的安全性機制。最後，我們將說明系統上的其他元件如何觀察系統是否選擇不接收更新。

提振精神

根據客戶要求，我們必須允許 Fuchsia 裝置使用者選擇不接收更新。我們必須滿足這項規定，盡可能確保所有使用者 (無論是否選擇停用) 的安全。

利害關係人

協助人員：

pascallouis@google.com

審查者：

  • kevinwells@google.com - 軟體推送 (SWD)
  • ampearce@google.com - Security
  • pascallouis@google.com - Fuchsia 工程委員會 (FEC)

已諮詢：

  • borthakur@google.com
  • marvinpaul@google.com - 伺服器導入
  • gtsai@google.com - 伺服器實作
  • enoharemaien@google.com - Privacy
  • hjfreyer@google.com - Component Platform / FEC
  • 軟體交付團隊

社交：

這項 RFC 經過設計階段，並與軟體交付團隊、安全與隱私權團隊和客戶合作。

需求條件

本文中的「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」和「OPTIONAL」等關鍵字，應按照 IETF RFC 2119 的說明解讀。

  • 產品擁有者可允許使用者停用更新，也就是說，使用者的裝置不會下載或安裝任何更新 (產品擁有者指定的重大更新除外，包括重大安全性更新)。
  • 如果裝置已停用更新，且已執行恢復原廠設定 (FDR)，則應重新啟用更新。
  • 這項設定必須在重新啟動後仍有效，且不必由產品層級元件在每次啟動時重新設定 (這會導致產品層級元件與更新檢查之間發生競爭條件)。
  • 設定的啟用和儲存作業必須盡可能安全，以免攻擊者找到權限提升漏洞，讓裝置停用更新，並無限期保留該漏洞。
  • 如果產品擁有者決定不在建構中加入停用選項，則不得允許使用者在執行階段啟用該選項 (必須有靜態編譯時間旗標，才能完全停用這項功能)。
  • 我們必須掌握有多少使用者選擇不接收更新 (但不會知道是哪些使用者)，確保攻擊者不會利用這個選項持續存在安全漏洞。
  • 如果系統處於復原模式，則應一律允許更新。
  • 如果使用者手動要求更新 (即使更新已停用)，系統也應允許更新。
  • 這項功能僅適用於具備防竄改儲存空間的裝置，例如 Replay Protected Memory Blocks (RPMB)。我們沒有在沒有防竄改儲存空間的裝置上啟用這項功能的要求，但如果日後有需要，我們可以重新審查這項 RFC。
    • 注意：建議的設計並未限制我們只能採用安全儲存空間實作方式，但如果移除防竄改儲存空間這項規定，產品擁有者就必須在安全性方面做出取捨。

設計

omaha-client 是我們的正式版系統更新檢查工具。並與產品擁有者或代表執行的 Omaha 伺服器通訊。Omaha 用戶端和伺服器會定期協商要安裝的系統或套件版本。

我們建議產品擁有者在軟體交付設定中靜態建構旗標，在產品上啟用這項功能。

讀取及寫入停用選項值

新的 SWD 元件 (稱為 update-settings-storage) 會提供名為 fuchsia.update.config.OptOut 的 FIDL API，用於讀取這個選項，以及名為 fuchsia.update.config.OptOutAdmin 的 API，用於寫入這個選項。這個 API 必須在 SDK 中公開，才能讓產品層級的元件切換選項的值。

fuchsia.update.config.OptOutAdmin API 必須受到能力轉送和 Scrutiny 驗證的嚴格保護，確保未經授權的元件無法存取。

讀取使用 fuchsia.update.config.OptOut 的停用設定值，應允許系統中具有較寬鬆控制項的允許清單元件，而非 OptOutAdmin。這樣一來，系統和產品層級的元件就能根據裝置是否選擇不接收更新做出決策，並提供這項選項的設定和疑難排解檢視畫面。

停用持續性與安全性

提供 OptOut API 的元件 update-settings-storage 必須在重新啟動時保留停用設定的值，且必須將設定保留在受完整性保護的儲存空間中。舉例來說，如果儲存這項設定時沒有一併儲存雜湊和簽章，minfs儲存空間就會不安全，因此系統不允許這種做法。

我們建議使用防硬體竄改的儲存空間 (目前在 Fuchsia 裝置上，只有 RPMB 這個選項) 儲存這項停用設定。我們希望防竄改儲存空間具備的特性是：只能由已簽署的「信任的應用程式」寫入，或可偵測到惡意寫入。

這些儲存空間 API 位於必要 <0x0

更新檢查

在每次排定的更新檢查中，omaha-client 應使用 OptOut FIDL API 從 update-settings-storage 讀取資料，並使用 Omaha 通訊協定中的現有 updatedisabled 欄位，將停用值傳送至 Omaha。

如果系統在復原磁碟分割區上執行，updatedisabled 應一律為 false。同樣地，如果更新檢查是由使用者發起，updatedisabled 應一律為 false。

如果 Omaha 伺服器收到更新檢查要求，且 updatedisabled 等於 true，則應傳回該 Omaha 應用程式的回應 NoUpdate，但產品擁有者指定的重大更新除外。

如果裝置已停用更新，可以選擇完全不傳送任何 Omaha 更新檢查。不過，這種替代方案會拒絕產品擁有者指標，瞭解有多少使用者選擇不接收更新，也會拒絕產品擁有者推送重大更新 (視需要覆寫伺服器上的 updatedisabled 欄位)。

停用選項必須適用於 omaha-client 檢查更新的所有應用程式，包括系統更新和單一套件。

實作

實作作業將由 SWD、韌體、安全性和更新伺服器團隊負責。工作細目大致如下，應對應至要提交的 CL 鏈結。

軟體交付

  • 建立 fuchsia.update.config.OptOut FIDL API
  • 導入 update-settings-storage 元件
  • 在更新檢查時讀取 fuchsia.update.config.OptOut 中的 omaha-client，並轉送至 Omaha 伺服器做為 updatedisabled 標記 (除非裝置處於復原狀態，或檢查是由使用者發起)
  • 在 SDK 中公開 fuchsia.update.config，並將這兩種通訊協定加入允許清單。
  • 在 omaha-client 中新增 Cobalt 指標，計算已停用裝置的數量
  • 在「檢查資料」中公開 omaha-client 的停用設定

韌體 / 安全性

  • 透過「已驗證執行可信應用程式」(VX TA) 向 RPMB 公開 API，並僅在支援的裝置上靜態納入該 API
  • 修改 VX TA，在恢復原廠設定期間清除停用旗標 (這項作業已由 VX TA 仲介)

更新伺服器

  • 修改 Omaha 規則的產生方式，如果該應用程式的 updatedisabled 為 true，則針對所有應用程式更新檢查要求傳回 NoUpdate。

效能

系統或更新檢查效能應該不會受到明顯影響。 更新檢查不頻繁 (以小時為單位)，且對延遲不特別敏感。

人體工學

我們為這項設定提供的讀取 API，以及 Inspect 和 Cobalt 記錄的停用狀態，都有助於減少開發人員或使用者可能產生的困惑。

回溯相容性

據我們所知，這項 RFC 不會造成回溯相容性問題。

安全性考量

更新是 Fuchsia 最重要的安全防護功能。如果沒有更新，Fuchsia 團隊就無法修補平台中的安全漏洞。更重要的是，無論使用者是否選擇停用更新，只要裝置上存在這個程式碼，所有使用者都會面臨風險：如果攻擊者取得足夠的權限，就能變更停用更新設定，並提高永久存留的機率。

這項設計嘗試透過下列方式降低風險：

  • 將設定儲存在防竄改記憶體 (RPMB) 中
  • 只允許特定「已驗證執行」可信任應用程式 (TA) 修改設定
    • 只有在裝置處於鎖定模式，且已登入通過驗證的使用者 (完成開箱即用程序後)，才能存取 TA
    • VX TA 比 minfs 等等小得多，也簡單得多，而且幾乎完全由安全性和韌體團隊修改
  • 稽核及允許 TA 路由
  • 保留將重大更新 (由產品負責人定義) 推送至裝置的能力
    • 定義絕對必要更新的條件不在本 RFC 的範圍內
  • 我們會持續追蹤選擇停用的裝置數量，並在數量異常時發出快訊

但仍存在下列風險：

  • 我們無法控制會呼叫停用 API 的產品層級程式碼，因此必須確保只有高權限元件可以存取該程式碼
  • 如果攻擊者取得足夠的核心權限，仍可控制 update-settings-storage 或 VX TA，並要求修改設定

下列安全性改善措施目前不在範圍內，但未來可能會考慮：

  • 新增實體存在感規定 (使用者必須以某種方式與裝置互動，而不只是透過產品層級的元件)
  • 只能從開機載入器將設定設為可寫入。這項設定可防範核心遭到入侵，但會影響使用者體驗和跨平台一致性

隱私權注意事項

這項設計不會大幅影響使用者隱私權，因為所有記錄或傳播的停用狀態都會透過受隱私權保護的記錄服務 (透過 Inspect 的當機資料庫或 Cobalt) 進行。

測試

我們會整合測試 update-settings-storage 元件、與 omaha-client 的互動，以及 omaha-client 在各種停用狀態下產生的最終 Omaha 伺服器要求。

我們會透過「已驗證的執行作業信任的應用程式」，整合測試 RPMB API。

我們也會個別對每個元件中的實作項目進行單元測試。

最後，我們會與測試團隊合作，確保啟用這項功能的產品能進行端對端整合測試，與其他更新功能類似。

說明文件

我們需要為新的 FIDL API 和 OTA 流程說明文件新增說明文件。

缺點、替代方案和未知事項

「墓碑」版本

我們可以將「墓碑」版本推送至裝置，表示裝置將不再更新，藉此實作更新停用功能。

這項做法有顯著優點：

  • 停用設定會儲存在不可變更的「驗證開機中繼資料」中。這代表安全性更高。

這項做法也有一些顯著缺點：

  • 對於啟用這項功能的每項產品，我們都需要為推送的每個正常版本產生特定的「墓碑」版本。
  • 實際套用停用設定需要 OTA 更新，這違反了我們的規定。

將停用值儲存在可變動的儲存空間中

我們可以將停用值儲存在 minfs 中，避免一些複雜性，這樣就能將這項功能部署到更多產品。不過，如果攻擊者能取得 minfs 的寫入權限，就能輕易地無限期持續發動攻擊，並提升權限。相較於修改「已驗證執行」可信應用程式的狀態，取得 minfs 的寫入存取權可能容易許多，因為就表面積而言，VX TA 比 minfs 小得多，也更容易稽核。

如果使用者選擇停用，請完全略過更新檢查

如果使用者選擇停用，我們可以修改 omaha-client，完全不檢查更新。這有幾個缺點：我們無法取得 Omaha 的指標，瞭解有多少使用者選擇停用，而且產品負責人無法要求裝置進行重大更新。

既有技術和參考資料

Omaha 通訊協定包含 updatedisabled 旗標，主要就是因為這個原因：用戶端裝置會告知伺服器正在檢查更新，但不應執行下載和安裝作業。

Chrome 瀏覽器支援透過企業政策停用更新。這可能是潛在的 Fuchsia 裝置用途，但我們目前沒有企業政策規定。