FlatpakアプリのPermissionsポリシーを設計する｜サンドボックス範囲の確認と業務環境への適用判断

デスクトップLinux環境において、Flatpakは「アプリをシステムから分離して安全に動かす」仕組みとして広く使われています。しかし、業務端末やサーバー隣接のワークステーションで導入を検討する場合、どのアプリがどのリソースにアクセスできるかを把握しないまま運用を始めると、セキュリティポリシーの抜け穴になりかねません。

本記事では、Flatpakのサンドボックス設計の基礎から、パーミッション確認・上書き制御・検証・切り戻しまでを一本の流れで整理します。2026年時点の実環境（Fedora 40系・Ubuntu 24.04系・Flathub最新ポリシー）に沿った内容です。

Flatpakサンドボックスが業務環境で問題になる理由

Flatpakのサンドボックスは、アプリをホストのファイルシステムやデバイスから切り離すことを目的としています。理論上は強固な分離ですが、現実には多くのアプリがサンドボックスの外と通信するために広いパーミッションを要求します。

たとえば、ホームディレクトリ全体への読み書き権限（filesystem=home）を持つアプリは、秘密鍵や業務ドキュメントを含むあらゆるファイルにアクセスできます。デスクトップ向けアプリの利便性とセキュリティのトレードオフとして設計されているため、一般的な個人利用では問題になりにくくても、共有端末・ゼロトラスト環境・情報漏洩リスクを意識する業務では見直しが必要です。

運用現場で多く見られるのは、「Flatpakならサンドボックスだから安全」という先入観のまま、実際のパーミッション内容を確認せずに展開してしまうケースです。Flatpakのサンドボックスは、設計と管理が伴ってはじめて機能します。

パーミッションカテゴリの構造を把握する

Flatpakのパーミッションはアプリのメタデータ（metadataファイル）に記述され、主に次のカテゴリで構成されています。

• filesystem：ホストのファイルシステムへのアクセス範囲（home・host・個別パスなど）
• socket：Wayland・X11・PulseAudio・SSHエージェントなどのソケットへの接続
• device：カメラ・マイク・GPU・USBなどのデバイスアクセス
• feature：BluetoothやCanBusなどの特殊機能
• share：ネットワーク共有・IPCの有効化
• talk-name / own-name：D-Busサービスへの接続・所有

このうち業務環境で特に注意すべきは filesystem=home・filesystem=host・socket=ssh-auth・talk-name=org.freedesktop.* などです。これらはホストのリソースに広く触れる設定であり、最小権限の原則からは逸脱しています。

Portalは、Flatpakがサンドボックスを維持しながら外部リソースと安全にやり取りするための仕組みです。ファイル選択ダイアログ経由でのアクセスや、プリンターポータル経由の印刷などが代表例です。Portalを正しく実装しているアプリは広い filesystem 権限を要求せずに済むため、業務利用での評価ポイントになります。

現在のパーミッションを確認する手順

まず対象アプリのパーミッションを確認します。flatpak info コマンドにオプションを付けることで、アプリIDとともにパーミッション一覧を取得できます。

# アプリIDを確認する
flatpak list --app

# 特定アプリのメタデータを表示する
flatpak info --show-permissions com.example.AppName

出力には [Context] セクションが含まれ、filesystems=・sockets=・devices= といった行でパーミッションが列挙されます。

ユーザーまたはシステム管理者が追加した上書き設定（overrides）を確認するには、次のコマンドを使います。

# ユーザースコープの上書き設定を表示
flatpak override --user --show com.example.AppName

# システムスコープの上書き設定を表示
sudo flatpak override --system --show com.example.AppName

GUIで確認・変更したい場合はGNOME Softwareの「アプリの権限」画面や、Flatsealが利用できます。ただし、組織的な制御にはCLIによる管理を推奨します。設定内容をテキストとして扱えるため、構成管理ツールとの連携が容易になります。

業務環境向けポリシー設計のフロー

パーミッションポリシーの設計は、アプリの導入前評価・上書き設定の作成・展開の三段階で進めます。

導入前評価：要求パーミッションの査定

Flathubで公開されているアプリの場合、アプリページに「Permissions」セクションが掲載されており、事前に確認できます。それに加えて、テスト環境で実際に flatpak info --show-permissions を実行し、組織のセキュリティポリシーと照らし合わせます。評価の基準として、現場では次の観点が参考にされています。

• ホームディレクトリ全体（filesystem=home）を要求しているか
• ネットワーク（share=network）とファイルアクセスの両方を持つか
• SSHエージェントソケット（socket=ssh-auth）へのアクセスがあるか
• Portalを使った代替手段で同等の動作が得られるか

上書き設定の適用

flatpak override コマンドを使うと、アプリのデフォルトパーミッションを個別に制限できます。システムスコープでの適用には管理者権限が必要です。

# ホームディレクトリアクセスを拒否する
sudo flatpak override --system --nofilesystem=home com.example.AppName

# ネットワークアクセスを拒否する
sudo flatpak override --system --unshare=network com.example.AppName

# 特定ディレクトリのみ読み取り専用で許可する
sudo flatpak override --system --filesystem=/opt/shared-docs:ro com.example.AppName

上書き設定はアプリのメタデータを変更するのではなく、システムまたはユーザーの設定ファイル（/var/lib/flatpak/overrides/ または ~/.local/share/flatpak/overrides/）に記録されます。アプリのアップデートによって元に戻ることはないため、更新後も設定は維持されます。

設定の検証と切り戻し

上書き設定を適用した後は、アプリが想定通りに動作するか、かつ制限が有効になっているかを確認します。

動作確認の基本は、アプリを起動してファイル操作・ネットワーク接続など制限対象の機能を試みることです。Flatpakはアクセス拒否をサイレントに処理することが多いため、アプリ側のエラーメッセージだけでなく、システムのジャーナルも併せて確認します。

# アプリ実行中のアクセス拒否ログを確認する
journalctl --user -f | grep -i flatpak

制限が強すぎてアプリの業務機能が損なわれる場合は、設定を段階的に緩和します。一方、想定外のアクセスが起きている場合はさらに制限を加えます。設定を元に戻す（切り戻す）には次のコマンドを使います。

# 特定アプリの上書き設定をすべてリセットする
sudo flatpak override --system --reset com.example.AppName

# リセット後に上書き設定が消えていることを確認する
sudo flatpak override --system --show com.example.AppName

切り戻しはアプリをアンインストールしなくてもよく、設定ファイルの削除で完結します。展開後に問題が発覚した際のリカバリが容易な点は、運用観点でのFlatpakの強みのひとつです。

2026年時点の現行環境差分と注意点

Flatpakのエコシステムは2024〜2026年にかけていくつかの重要な変化を迎えています。業務環境への適用を検討する際は、これらの差分を把握しておく必要があります。

Flathubの検証ポリシー強化：2024年後半からFlathubは提出アプリのパーミッション審査を厳格化し、不必要な filesystem=home を要求するアプリへの再審査を求める動きが続いています。Flathub経由のアプリは以前より過剰なパーミッションが減りつつありますが、古いアプリや非FlathubリポジトリのFlatpakでは旧来の広いパーミッションが残っていることがあります。リポジトリの出所ごとに信頼レベルを分けて管理することが重要です。

WaylandとPortalの成熟：GNOME 47以降・KDE Plasma 6系の普及により、ファイルピッカーポータル・スクリーンキャプチャポータルの対応アプリが増えています。Wayland環境では socket=x11 が不要になるアプリも多く、移行状況をパーミッション内容で確認することで、アプリのWayland対応度の目安にもなります。業務端末をWaylandセッションに統一することで、X11ソケット経由のアクセスを構造的に排除できる点も評価されています。

Fedora・UbuntuのFlatpak標準化動向：Ubuntu 24.04 LTSではFlatpakがデフォルト収録から外れていますが、Flatpakパッケージ自体は引き続き標準リポジトリから導入可能です。Fedora Workstation 40以降ではFlatpakが事実上の主要アプリ配布手段となっており、GNOME Softwareとの統合が進んでいます。組織内での統一展開には、Fedora環境が現時点でより成熟しています。

管理ツールの選択肢：大規模展開では flatpak override のスクリプト化に加え、AnsibleロールやFleet管理ツールとの組み合わせが現場で採用されています。上書き設定ファイルはテキストで構成管理できるため、GitOpsと親和性が高く、設定ドリフトの検出にも利用されています。定期的な差分チェックをCIに組み込むことで、アプリ更新に伴う意図しないパーミッション変化を検知する仕組みを整えることができます。

パーミッションポリシーの設計は「一度決めたら終わり」ではなく、アプリのアップデートやFlatpakランタイムの更新に合わせた継続的な見直しが求められます。定期的な flatpak info --show-permissions の実行と、上書き設定のバージョン管理が業務環境での基本的な運用サイクルになります。