Flatpakアプリケーションのシークレット管理への3つのアプローチ

Flatpakを使用すると、デスクトップアプリケーションを分離されたサンドボックスで実行できます。これにより、アプリケーションが相互に影響を及ぼしたり、ホストシステムに影響を与えたりするのを防ぐため、セキュリティが大幅に向上します。ただし、実際には、通常のアプリケーションは、他のアプリケーションやホスト間で共有されるサービスやユーザーデータにアクセスする必要があります。この状況は、ポータルメカニズムに関する権限を強化することで改善されましたが、長年の問題であるユーザーシークレットの管理方法がありました。

この記事では、Flatpakアプリケーションのユーザーシークレットを管理するためのアプローチを紹介します。ほとんどのアプリケーションは提案されたメカニズムを透過的に利用できますが、一部のアプリケーションではコードを変更する必要があります。移行手順も示されています。

​​Linuxデスクトップでのシークレットの管理方法

最新のLinuxデスクトップでは、ほとんどのシークレット（パスワード、トークンなど、およびそれらに関連付けられた属性）は、デーモンプロセス gnome-keyring-daemonによって一元管理されます。 。アプリケーションは、D-Busを介して公開されるシークレットサービスAPIを介してこのデーモンにアクセスします。このプロセスは、アプリケーションが libsecret などのクライアントライブラリを使用している場合、内部で実行されます。 。

注： 同じ目的で、 libgnome-keyringというライブラリがあります 、現在は廃止されています。名前にもかかわらず、 libgnome-keyring gnome-keyringとは別のプロジェクトです 、これは時代遅れではなく、秘密管理の中心的な役割を維持しています。

デーモン側では、シークレットはファイルシステムに保存され、暗号化されます。それ以外は、デーモンは通常のストレージサービスにすぎません。つまり、どのアプリケーションでも、他のアプリケーションが見ることができる任意の「パス」にデータを保存できます。このモデルは、すべてのアプリケーションを信頼する限り十分ですが、Flatpakのセキュリティ目標の1つである、アプリケーションを相互に分離することでデスクトップシステムのセキュリティを強化することを否定します。

したがって、シークレットサービスAPIを使用するFlatpakアプリケーションをインストールする場合、ユーザーはアプリケーションに必要な権限を付与するように求められます。以下の例では、アプリケーションがシークレットサービスAPI（ org.freedesktop.secrets ）へのアクセスを必要としていることがわかります。 ）。ユーザーがこのアプリケーションにサービスへのアクセスを許可したくない場合、唯一の選択肢はインストールを放棄することです。

$ flatpak install org.gnome.Epiphany

…

org.gnome.Epiphany permissions:

        ipc                     network         pulseaudio      wayland

        x11                     dri             file access [1] dbus access [2]

        system dbus access [3]



        [1] xdg-download, xdg-run/dconf, ~/.config/dconf:ro

        [2] ca.desrt.dconf, org.freedesktop.Notifications, org.freedesktop.secrets

        [3] org.freedesktop.GeoClue2

Proceed with these changes to the Default system installation? [Y/n]:

これは明らかに望ましくない結果です。

ローカルストレージアプローチ

この問題に取り組むための基本的な考え方は、ホスト側ではなくアプリケーション側にシークレットを保存することです（ gnome-keyring-daemon ）。この方法は、アプリケーションが設定データを dconfではなくローカルファイルに保存するGSettingsに関する最近の作業に類似しています。 ホストで実行されているサービス。

ただし、シークレットに関しては、ブートストラップの問題があります。アプリケーションは、シークレットをローカルファイルに保存するときにシークレットを暗号化する必要がありますが、暗号化キーをまだ認識していません。暗号化キーを使用してアプリケーションをプロビジョニングするには、Flatpakポータルメカニズムを使用します。Flatpakポータルメカニズムは、アプリケーションとホストの間に位置し、制限されたインターフェイスを介して2つが通信できるようにします。

また、アプリケーションが暗号化キーを取得できるようにする新しいポータルを追加しました。最初に、アプリケーションはポータルに要求を送信します（要求には、暗号化キーが書き込まれるUnixファイル記述子が含まれます）。次に、ポータルはリクエストを gnome-keyring-daemonのバックエンド実装に委任します 、ファイル記述子を介してサンドボックス化されたアプリケーションの一意の暗号化キーを送信します。

受信した暗号化キーを使用して、アプリケーションはシークレットを暗号化し、アプリケーションデータディレクトリ（〜/.var/app/$APPID/data/keyrings ）に保存します。 ）、これはバインド -マウントされ、ホストとサンドボックスの両方からアクセスできます。

libsecret API

libsecret プロジェクトは、2つの異なるAPIセットを提供します。 1つは単純なAPIで、も​​う1つは完全なAPIです。前者はシークレットを取得して保存するためのよりシンプルでステートレスな操作を提供し、後者はD-BusインターフェースをCAPIにマッピングするより完全なオブジェクト指向APIを提供します。

ローカルストレージは、シンプルなAPIでのみサポートされています。アプリケーションがすでにシンプルなAPIを使用している場合、Flatpakで実行すると、アプリケーションは自動的にローカルストレージを使用します。それ以外の場合、ローカルストレージを有効にするには、アプリケーションをシンプルなAPIに移植する必要があります。例として、Epiphanyの移行パッチを参照してください。

2つのAPIセットを区別することで、アプリケーションがローカルストレージの使用をオプトアウトすることも可能になります。たとえば、アプリケーションがユーザーキーリングへのフルアクセスを必要とするパスワードマネージャーである場合、完全なAPIを使用してローカルストレージをバイパスできます。

キーリングの形式

理想的には、ローカルストレージと gnome-keyring-daemonの両方に同じキーリング形式を使用できる必要があります。 、 gnome-keyring-daemonで使用されるキーリング形式に気づきました 制限があります。関連する属性を含むシークレットは単一のチャンクとして暗号化されます。つまり、シークレットは不必要な量のロックされたメモリを消費する可能性があります。また、属性はキーなしでハッシュされます。つまり、ファイルに保存されているシークレットを推測することができます。

そのため、この形式を2か所で実装する代わりに、次の特徴を備えた新しいバージョンのキーリングファイル形式を定義することにしました。シークレットは個別に暗号化され、属性ハッシュは属性に対するメッセージ認証コード（MAC）になりました。

この新しい形式は、ヘッダーを除いてGVariantシリアル化形式に基づいており、この変更により、エンコード、デコード、およびルックアップにほとんどのコードを再利用できます。

Flatpakシークレット管理の次のステップ

必要なパッチは、（現在）関連するコンポーネントのGitリポジトリ（ xdg-desktop-portal ）でのみ利用できます。 、 gnome-keyring 、および libsecret ）。これらは、GNOME3.36に至るまでの次のリリースに含まれる予定です。

開発者の場合、この領域にはまだ改善の余地があります。ここにあなたの助けが大いに感謝されるところです：

• セッションキーリング： シークレットサービスAPIは、「セッション」キーリングをサポートしています。このキーリングは、ユーザーセッションの間だけ持続します。ローカルストレージバックエンドはまだこの機能をサポートしていません。このコードは、Linuxカーネルのセッションキーリングを使用して実装できます。

• 管理およびバックアップアプリケーション： アプリケーションシークレットは、ホストキーリングだけでなく、複数の場所に保存されるようになりました。アプリケーションシークレットを管理し、バックアップを作成するためのツールがあれば便利です。このプロセスは、アプリケーションの秘密を調べるためにGNOMEのタツノオトシゴを強化することで可能になるはずです。

• オンラインアカウントポータル： 最近では、WebアプリケーションがOAuth2.0などのWebベースのアクセス委任プロトコルと統合されるのが一般的です。これらのプロトコルは、 gnome-online-accountsによってサポートされています 、次に gnome-keyring-daemonを使用します トークンを保存するため。オンラインアカウントのポータルインターフェイスは、アプリケーションごとのアクセスを制限するのに役立ちます。

• 新しいキーリング形式の幅広い採用： 新しい形式にはいくつかの利点がありますが、現在は libsecretによってのみ使用されています。 アプリケーション側で。 gnome-keyring-daemon があれば、それは有益です。 ホスト側でも同じ形式を使用しました。

• 再インストールプロセスの強化： デフォルトでは、アプリケーションのキーリングファイル（〜/.var/app/$APPID/data/keyrings ）他のデータとともに、アンインストール後も存続します。アプリケーションIDが信頼できない発行者によって再利用された場合、この永続性は脆弱です。現在、-delete-dataを使用することをお勧めします そのようなアプリケーションデータが削除されることを保証するオプション。出版社のIDがアプリケーションに関連付けられている場合、この手順は改善される可能性があります。

概要

この記事では、Flatpakアプリケーションにユーザーシークレットをプロビジョニングするメカニズムを紹介しました。このメカニズムは、次の原則に基づいて設計されました。

• ホストインターフェイスを最小化します。
• アプリケーションがFlatpakポータルを介してホストと対話できるようにします。
• アプリケーションデータを一般的なデータ形式で保存します。

メカニズムは透過的ですが、 libsecretを使用している限り 、メカニズムは libsecretを介してのみ有効になります のシンプルなAPI。スムーズな移行のために、アプリケーションをこのAPIに移行することをお勧めします。プロジェクトの背景と設計の根拠に関する詳細は、GUADECプレゼンテーション（スライド、記録）で入手できます。