はじめに

このプロジェクトは、グラフィカルなアプリケーションを実行するために、コンテナを使用してホストシステムとの分離を提供することを目指しています。Dockerを使用してこれを実現する、セキュリティに焦点を当てたプロジェクト（x11docker）が少なくとも1つありますが、私はlxdコンテナを使用したいと思いました。Linuxホストには、Xサーバのソケットファイルをコンテナで共有するというシンプルなソリューションがあります。ソケットにアクセスすることで、コンテナがホストのキーボード、ビデオ、マウス、クリップボードにアクセスできるようになるので、これを避けたかったのです。

新しいWaylandディスプレイサーバーシステムは、最終的にXに取って代わり、Xが持つ共有リソースのセキュリティ問題を緩和します。しかし、XクライアントがWaylandで実行できるようにする互換性レイヤーをアプリケーションが利用する場合、この問題はまだ存在する。Waylandは2012年から存在しており、2018年第3四半期時点ではいくつかのGUIツールキットが互換性を持っている。注目すべきは、Firefoxがまだ互換性がないことだ。Project Crostiniはこの問題を解決しているかもしれません。このプロジェクトの目標は、LXDを使ってChrome OSでLinuxアプリを実行することです。

ホストリソースをほとんど使わず、セットアップが簡単で、ユーザーフレンドリーでありながら、アプリをできるだけ分離することが目標です。当初のユースケースはFirefoxでしたが、他のアプリにも対応できるよう汎用性を保つよう努力しました。

このプロジェクトのツールは、基本的にLXDとxpraのラッパーに過ぎません。

概要

Dockerやlxdのようなコンテナは、ホストシステムに対してある程度の分離を提供しますが、その主な目的はソフトウェアの移植性と一貫性です。ホスト側にコンテナ管理ソフトウェアがインストールされていれば、ホストのハードウェア、OS、ライブラリ、アプリケーションに関係なく、コンテナは同じように動作するはずです。コンテナは、アプリケーションの実行に必要なすべてのものを保持するパッケージ化されたユニットです。

一方、システム仮想マシン（VM）またはハイパーバイザーは、ハードウェアをゲストに仮想化し、ホストや他のVMとの高度な分離を提供します。ゲストVMのために個別のリソースが作成されます。もう一方の端にあるアプリケーション・サンドボックスはより軽量な隔離メカニズムで、通常隔離を行うためのリソースは少なくなりますが、そうすることでホストとの共有リソースや他のコンテナとの間接的なリソースに依存することになります。

分離の種類

• システム仮想化（VM、ハイパーバイザー）
  • VMware、VirtualBox、QEMU-KVM、Xen、Qubes OS、Multipass
  • Qubes OS - 活動をドメイン（AppVMs [Xen仮想マシン]）に区分けする。
• OSの仮想化（＝コンテナ）
  • Docker、LXD、Rocket、ユーザモードLinux
• アプリの仮想化（つまり、サンドボックス）
  • Firejail - コード、ブログシリーズ、チュートリアル、比較。“Linuxの名前空間とseccomp-bpfを使用して、信頼できないアプリケーションの実行環境を制限する”。セキュリティプロファイルはアプリごとに作成され、何を制限するかを定義するために使用されます。これは AppArmor に似ており、プロファイルはアプリの更新と同期させる必要がある。
  • Bubblewrap - Firejailに似ているが、よりシンプルで機能が少ない。手動での作業が必要。
  • Sandboxie - Windowsのみ。OSの一部をインストルメント化し、特定のアプリのために個別のリソースを作成する。詳細はFAQにあります。
  • chroot (a.k.a chroot jail) - アプリがファイルシステムのルートとして見るものを変更します。
  • gVisor (“not a sandbox”) - アプリケーションとホストカーネルとの間に分離境界を提供するユーザースペースカーネル。“seccomp on steroids” (ステロイドの seccomp)
  • Oz (Subgraph OSが使用するサンドボックス) - Linuxの名前空間、seccompのフィルタ、機能、X11の分離を使用し、実行可能ファイルを透過的にラップする。OSは、grsecurity、PaX、RAPによって強化されたLinuxカーネルと、Ozというカスタムサンドボックスを使用する。
  • Subuser - Dockerコンテナ内のアプリを分離し、XPRAを使用してGUIを分離します。“Dockerコンテナをアプリに変身させる”
  • Snap package - サンドボックス化されたソフトウェアパッケージ。Goで書かれている。ライセンスはGPL 3.0。パッケージングツール、リモートストアからの自動更新、バージョニングを提供します。アプリは「コンファインメント」を使ってホストや他のアプリから隔離される。アクセスのためのパーミッションは、パッケージのメタファイルで宣言するか、ホストのコマンドラインツールを使って手動で宣言する必要があります。自己完結型：すべてのコード、読み取り専用データ、および非コアライブラリは、読み取り専用のSquashFSイメージに格納されます。コアライブラリは、コアスナップによって提供されます。セキュリティ強化メカニズム AppArmor、seccomp、cgroups、およびnamespaces。
  • Flatpakパッケージ - サンドボックス化されたソフトウェアパッケージ。C言語で書かれており、ライセンスはLGPL 2.1。Snapに似ている。以前は “xdg-app”と呼ばれていた。セキュリティ強化の仕組みとして、seccomp, cgroups, namespaces, bind mountsを利用したbubblewrapを採用している。アプリのバージョン間で同一のファイルは、スペースを節約するために重複排除される。
  • AppImage パッケージ - 自己完結したイメージでアプリを配布するためのフォーマット。C言語で書かれており、ライセンスはMITです。セキュリティは目的ではありません。類似プロジェクトとの比較
• ルールベース (Linux Security Modules (LSM)) - AppArmor、SELinux、seccomp

GUIアイソレーションの種類

• 仮想デスクトップ
  • RDP、VNC、NX。遅すぎるし、シームレスではない
• シームレス - Xフォワーディングを使ったSSH、NX、xpra
  • xpra - ダミー (xvfb) ディスプレイサーバ (Xorg) をセットアップし、本質的にターゲットアプリのウィンドウマネージャになる。Xクライアントからxpra接続を介して実際のディスプレイにGUIをプロキシする。ウィンドウは、実際のディスプレイの一部であるかのように見え、感じられます(通常のデスクトップウィンドウのようにサイズ変更可能でフレーム化されます)。Ubuntuのデフォルト・パッケージでは、誰でもXサーバーを起動できるようにするために、 Xwrapper.configファイルを変更する必要があります。xpraの新しいバージョンで修正されたと思います。
• 共有Xサーバ - Xソケットをアプリと共有します。アプリがホストの入力イベントを傍受できるため、安全性が低い。
  • ホストベースのアクセスコントロール - xhost + はアクセスコントロールを無効にします、xhost local: は全てのローカルユーザーを許可します、xhost si:localuser:#1001000 はコンテナーユーザーを許可します。
  • クッキーベースのアクセス制御 - MIT-MAGIC-COOKIE-1 を生成して、ホストとコンテナの両方で xauth add… を使用しますが、これにはいくつかのステップが必要です。xauth generate…やxauth extract…を使うこともできるが、表示名のホスト部分がコンテナのホスト名を指定するように簡単に設定することはできない
• ネストしたXサーバ - Xephyr, Xnest. シームレスではない

目標

• ユーザーフレンドリー - グラフィカルアプリケーションウィンドウとネイティブデスクトップの統合（ルートレスまたはシームレスなど）
• ユーザーフレンドリー - パフォーマンスとホストリソースへの影響を最小限に抑える
• ユーザーフレンドリー - クリップボード、サウンド、ファイル転送
• ホストの分離 - ディスプレイサーバへのアプリケーションのアクセス制限
• メンテナンス性 - アップストリームアプリのアップデートにより、ホストアイソレーションの仕組みが壊れることはありません。
• セキュリティ - セキュリティコントロールとしてではなく、アプリのパッケージングとデプロイのメカニズムとして分離を提供することの区別があります。

制限事項

• コンテナから取り出されるイメージは、最新の安定版Ubuntuです（つまり、lxd initコマンドには、リモートとして “ubuntu:”とNullイメージが渡されます）。
• 複雑さを軽減するために、いくつかのものはハードコードされています（例：コンテナ内のディレクトリとバインドマウントのホスト）。
  • xpraのバインドマウントは、コンテナ内の/home/ubuntu/.xpraにハードコードされています。
  • ファイル共有のバインドマウントは、コンテナ内の/home/ubuntu/shareにハードコードされます。
  • マップされたファイルのバインドマウントは、コンテナ内の/home/ubuntu/maps/にハードコードされています。
• コンテナソフトを最新に保つことは、ユーザーに任されている。しかし、おそらくそれはすでにコンテナOSによって処理されています。
• 非特権コンテナを使用すると、ファイルを共有するために多くの労力が必要になります。そこで、コンテナユーザーとホストユーザーが読み書きできるように、バインドマウントにACLを使用することで対応します。このコンテナ・ユーザは、すべてのコンテナで同じです。
• コンテナ・ユーザー ID は 1001000 にハードコードされています。
• コンテナ・ネットワークはデフォルトのブリッジを使用し、SSH は「ubuntu」ユーザー名と IPv4 を使用するようハードコードされています。
• ディスプレイの番号は、Bash の $RANDOM パラメータのような小さなエントロピー源で選択されるため、クライアントが既存のディスプレイに接続しようとする可能性がある。
• コンテナにマップされたファイルに改行文字があると、問題が発生することがあります。
• マッピングされたファイルのパーミッションが、マッピング後にホストまたはコンテナ・ユーザによって変更された場合、元のパーミッションに戻されない可能性があります。

ソフトウェア情報