RFC-0150：選擇不更新

RFC-0150：更新選擇退出
狀態已接受
區域
  • 軟體推送
說明

產品擁有者適用的政策和功能，方便使用者選擇停用軟體更新。
問題
  • 110
變更
作者
審查人員
提交日期 (年/月)2022-01-14
審查日期 (年/月)2022-01-31

編輯此 RFC

編輯 RFC 中繼資料

摘要

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

提振精神

我們要求客戶允許 Fuchsia 裝置的使用者退出更新。無論使用者的停用狀態為何，我們都必須盡可能確保所有使用者的安全

相關人員

講師：

pascallouis@google.com

審查者：

  • kevinwells@google.com：軟體推送 (SWD)
  • ampearce@google.com - 安全性
  • pascallouis@google.com - Fuchsia Engineering Council (FEC)

顧問：

  • borthakur@google.com
  • marvinpaul@google.com - 伺服器實作
  • gtsai@google.com - 伺服器實作
  • enoharemaien@google.com - 隱私權
  • hjfreyer@google.com - 元件平台 / FEC
  • 軟體推送團隊

社群媒體化：

這個 RFC 與軟體推送團隊、安全性和隱私權團隊及客戶一起完成設計階段。

相關規定

本文件中的重要字詞「必須」、「不得」、「必要」、「應」、「不應」、「應該」、「不應該」、「建議」、「可能」和「選用」均採用 IETF RFC 2119 說明。

  • 產品擁有者可允許使用者選擇不採用更新，這表示除非產品擁有者指定的重大更新 (包括重大安全性更新)，否則應用程式不會下載或安裝至使用者的裝置更新。
  • 如果裝置已選擇不更新，並已執行恢復原廠設定 (FDR) 功能，則應重新啟用更新。
  • 此設定必須在重新啟動後保持不變，不需要在每次啟動時由產品層級元件重設 (這會導致產品層級元件與更新檢查之間發生競爭狀況)。
  • 該設定的啟用和儲存作業必須盡可能安全，以防止攻擊者發現權限提升情況、將裝置退出更新功能，並無限期保存該安全漏洞。
  • 如果產品擁有者未決定在建構作業中加入停用選項，使用者就無法在執行階段啟用選擇停用選項 (必須使用靜態編譯時間標記才能完全停用該功能)。
  • 我們必須有指標指出停止更新服務的使用者人數 (而不是特定使用者) 人數，確保攻擊者不會利用這個選項持續存在安全漏洞。
  • 如果系統處於復原模式，則一律允許更新。
  • 如果使用者手動要求更新，即使在停用更新的情況下仍應允許該更新。
  • 建議只在裝置上啟用防竄改儲存空間，例如重播保護記憶體區塊 (RPMB)。我們沒有在沒有防竄改儲存空間的裝置上啟用這項功能，但日後如有需求，我們可以重新審視這個 RFC。
    • 注意：建議的設計不只會限制我們只安全地實作儲存空間，移除防竄改儲存空間功能，這可能導致產品擁有者在安全性方面有所取捨。

設計

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

我們建議產品擁有者透過在 Software Delivery 設定中的標記進行靜態建構，藉此在產品上提供這項功能。

讀取並寫入選擇退出選項的值

名為 update-settings-storage 的新 SWD 元件將提供名為 fuchsia.update.config.OptOut 的 FIDL API 以讀取這個選項，以及名為 fuchsia.update.config.OptOutAdmin 的 API 以寫入此選項。這個 API 必須顯示在 SDK 中，才能讓產品層級元件開啟或關閉選項的值。

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

使用 fuchsia.update.config.OptOut 「讀取」停用設定的值，應允許其控制項較 OptOutAdmin 以上的系統元件加入許可清單。這樣一來，系統和產品層級的元件就能根據裝置是否停用更新來判斷，並提供此選項的設定和疑難排解檢視畫面。

選擇不使用持續性和安全性功能

提供 OptOut API 的元件 (update-settings-storage) 必須在重新啟動後保留選擇停用設定的值，且必須在完整性保護儲存空間中保留該設定。舉例來說，如果 minfs 儲存這項設定，但儲存空間中未隨附雜湊和簽名，就會不安全，且系統會禁止使用。

建議您使用硬體防遭竄改的儲存空間 (目前在 Fuuchsia 裝置上只能使用 RPMB 選項)，以便儲存這項停用設定。我們想要的是防竄改儲存空間，屬性只能寫入已簽署的「受信任應用程式」，或是可以偵測惡意寫入。

透過

更新檢查

在每個排定的更新檢查中，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 元件
  • 在更新檢查時從 omaha-client 讀取 fuchsia.update.config.OptOut，然後以 updatedisabled 標記轉送至 Omaha 伺服器 (除非裝置處於復原作業，或檢查作業是由使用者啟動)
  • 在 SDK 中公開 fuchsia.update.config，並將兩個通訊協定加入許可清單。
  • 在 omaha-client 中新增 Cobalt 指標，計算已選擇停用的裝置數量
  • 在「檢查 omaha-client」的資料中顯示停用設定

韌體 / 安全性

  • 透過已驗證的受信任應用程式 (VX TA) 向 RPMB 公開 API，並以靜態方式將其納入支援的裝置上
  • 修改 VX TA，在恢復原廠設定期間清除選擇退出標記 (該標記已經過調解)

更新伺服器

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

效能

系統或更新檢查效能應該不會造成任何顯著的影響。更新檢查次數不頻繁 (以小時為單位)，更不會特別容易受到延遲影響。

人體工學

這項設定的 Read API 有助於減少可能的開發人員或使用者混淆，以及檢查和 Cobalt 選擇拒絕狀態的記錄。

回溯相容性

此 RFC 沒有任何已知的回溯相容性問題。

安全性考量

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

此設計嘗試以下列方式降低風險：

  • 將設定儲存在防竄改記憶體 (RPMB) 中
  • 僅允許特定已驗證執行的應用程式 (TA) 修改設定
    • 裝置處於鎖定模式，且已驗證使用者 (在 OOBE 之後) 才能存取 TA
    • VX TA 比如 Minfs 等小很多，而且安全性和韌體團隊幾乎獨自修改
  • 稽核 TA 轉送作業並加入許可清單
  • 保有將重大更新 (由產品擁有者定義) 推送至裝置的功能
    • 定義絕對必要更新的條件不在這個 RFC 的範圍內
  • 我們會持續得知選擇停用的裝置數量，並可在偵測到可疑的裝置時發出快訊

下列風險仍存在：

  • 我們對於會呼叫選擇不採用 API 的產品層級程式碼沒有控制權，且必須確保只有高特殊權限的元件才能存取此程式碼
  • 已取得足夠的核心權限的攻擊者仍可控制 update-settings-storage 或 VX TA，並要求對方修改設定

下列安全性改善項目目前不在範圍內，但可在日後的版本中納入考量：

  • 新增實體存在要求 (除了透過產品層級元件與裝置互動時，使用者必須以某種方式與裝置互動)
  • 將設定設為只能透過系統啟動載入程式寫入。這樣可以防止設定受到核心入侵，但使用者體驗和跨平台的一致性也會隨之降低

隱私權注意事項

這項設計不會對使用者隱私造成太大影響，因為所有記錄或傳播作業都採用隱私保護的記錄服務：我們的當機資料庫透過檢查功能或 Cobalt。

測試

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

我們將透過已驗證的受信任應用程式，進行 RPMB API 的整合測試。

我們也會分別測試每個元件的實作結果。

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

說明文件

我們需要新增說明文件至新的 FIDL API，以及 OTA 流程說明文件。

缺點、替代方案和未知

「Tombstone」版本

我們可以將「Tombstone」版本推送到裝置上，藉此導入更新退出機制。

這樣做的優勢在於：

  • 選擇不採用設定儲存在驗證開機程序中繼資料中 (不可變更)。這表示安全性屬性會較高。

這種做法有一些值得注意的缺點：

  • 我們需要針對每個啟用此功能的產品，產生一個特定的「Tombstone」版本。
  • 您必須更新 OTA 更新，因此必須採用不符合 Google 要求的 OTA 更新程序。

將選擇設定的值儲存在可變動儲存空間

我們可以將選擇停用的值儲存在 Minfs 中，進而避免作業變得複雜，以便將這項功能部署至更多產品。但是，這會讓具有權限提升能力的攻擊者在獲得 Minfs 寫入權限時，能夠無限期保留其攻擊。比起修改已驗證的受信任應用程式狀態，取得 Minfs 的寫入存取權可能比修改已驗證執行受信任應用程式的狀態高出許多，因為 VX TA 遠小於途徑區域的最小值，且更容易稽核。

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

如果使用者選擇退出，我們可以修改 omaha-client，完全不檢查更新。 懷特挑戰上的入同步處理指標，

先前的圖片和參考資料

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

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