Xorgアプリケーションを刑務所に閉じ込める目的は、そのアプリケーションへのアクセスを防ぐことです。@/tmp/X11/X0そして/tmp/X11/X0その後、再利用してください。MITマジッククッキーXサーバーに接続されている他のアプリケーションから盗みます。
このクッキーは、アプリケーションが最初に接続されたときにXorgのファイルハンドル/ソケット抽象化を取得するために使用されます。悪意のあるハッカーがアプリケーションをセグポートしてシェルを起動すると、このファイルハンドル/ソケット抽象化にアクセスできなくなるため、元のMIT-MAGIC-COOKIEが必要です。.X 権限そして彼は新しいXorgコンテキストを生成するために/tmp/X11/X0ファイル/abstract-socketにアクセスする必要があります。
FirejailとLinuxの名前空間の基本的なアイデアは、これらのリソースを隠して新しいXorgコンテキストを作成するのを防ぐことです。
この目的のために、FirejailはLinuxネームスペースを使用し、アプリケーションを/ tmp / *が存在しない新しいネームスペースに移動します。また、以下を使用してアプリケーション用の新しいブリッジインターフェイスを提供します。--ネットワーク=したがって、アプリケーションは.Xauthorityファイルを表示できず、Xorgと通信できません。アプリケーションはブリッジインターフェイスを介して通信するため、インターネットを見ることができます/許可されていると仮定しますが、そのビューはbr0などのファイアウォールによって制限されます。
アプリケーション自体は、Xorgソケットポインタを使用して共有メモリを使用するXorgと通信し、ポインタを保持する限り無期限に通信できます。
それでは、Firejailセキュリティはメモリ内で完全にクラッシュし、Xorg CONTEXT /ポインタを失うアプリケーションに依存していますか？ しかし、ハッカーがアプリケーションにセグフォルトしようとし、コードを書き換えながらもXorgコンテキストを維持することはできますか？しかし、これは私たちが受けなければならないリスクであり、おそらく次の方法で回避できます。衣類/SELinuxシステムコールを監視しますか？
しかし、なぜ私たちは使用しないのですか？名前付きパイプ代わりに？名前付きパイプ/.Xauthorityを作成します輸出許可アプリケーションを起動します。ブロックされているため、サーバー側で現在のCookieを作成し、アプリケーションの起動後にそれを変更するいくつかのプログラムを実行します。したがって、アプリケーションセグフォルトが発生し、ハッカーが一般ユーザーである場合、またはCookieに制限がない場合、ハッカーは新しいCookieを盗む希望はまったくありません。特に、ユーザーを消去または削除したり、すべてのファイルを削除して再実行を開始したりする場合は、さらにそうです。各アプリケーション。
Firejailはこれをどのように異なる方法ですか？アプリケーションを起動する必要がある場合は、.Xauthorityファイルとソケットファイルを提供する必要があります。それでは彼は何をしますか？アプリケーションを新しいNSに移動しますか？移動時期をどのように知ることができますか？多くのアプリケーションが.Xauthorityを複数回ポーリングしていますが、Firejailはこれらのリソースを非表示にするタイミングをどのように知り、正確にどのように非表示にしますか？
ベストアンサー1
Xorgアプリケーションを刑務所に配置する目的は、@ / tmp / X11 / X0および/ tmp / X11 / X0にアクセスし、MIT-MAGIC-COOKIEを再利用してXサーバーに接続されている他のアプリケーションを盗むことを防ぐことです。
いいえ？例えば読むとこのガイド、
サンドボックスは通常のX11サーバーをXpraまたはXepyrサーバーに置き換えます。これは、X11キーロガーとスクリーンショットユーティリティがネイティブX11サーバーにアクセスするのを防ぎます。
したがって、Xアプリケーションを刑務所に配置する目的は、Xアプリケーションがプライマリサーバーにアクセスするのを完全にブロックし、代わりにプロキシサーバーにアクセスすることを許可することです。アプリケーションがプロキシサーバーを使用しようとすると、プライマリサーバーには影響しません。
あなたが説明する特定のシナリオが何であるかはわかりませんが、MIT Cookieを使用するための初期認証がアプリケーション自体で行われていない場合でも、何らかの方法でプライマリサーバーにアクセスできるXアプリケーションはこのサーバーに存在する可能性があります。 。キーロギングや他のウィンドウにアクセスするのと同じです。これを行うために競合する必要はありません。したがって、最初にアプリケーションを承認してから再承認されるのを防ぐことは役に立ちません。
特定の方法で刑務所に閉じ込められたアプリケーションを実行する目的がプロキシXサーバーにアクセスできるようにすることを見逃した可能性はありますか？
編集する
私は刑務所に閉じ込められたアプリケーションを保護するために、Firejailが伝統的なxauth / .Xauthorityの慣行とどのように異なるかを理解しようとしています。
FirejailはXサーバープロキシをアプリケーションに公開し、アプリケーションがプライマリXサーバーにアクセスするのを防ぎます。それはすべてです。従来の xauth メカニズムは、アプリケーションと X プロキシ間であれ、X プロキシとプライマリ X サーバー間であれ、まったく同じです。 （はい、確かにXエージェントがメインサーバーにアクセスする必要があるか、メインXサーバーとXエージェントの両方にアクセスできるプログラムが必要です。しかし、これらのプログラムは信頼できる、アプリケーションとは異なり）。
その後、名前空間を使用してクッキーが漏洩するのを防ぎ、Xorgソケットを隠すための追加の措置として使用します。
いいえ。名前空間の目的は、基本的なXサーバー通信エンドポイントにアクセスできないようにすることです。それは「彼らは存在しない」のようです。実際には何も「隠さない」（「そこには見えません」）。収容されたアプリはもう存在しません。同様に、Dockerコンテナは名前空間を使用して、コンテナ内のアプリケーションがまったく異なる環境で実行されているかのように偽装できるようにします。
刑務所に閉じ込められたアプリケーションがネイティブXサーバー通信エンドポイントを表示できないようにするだけで十分ですが、刑務所に閉じ込められたアプリケーションがネイティブXサーバーの有効なMIT Cookieを表示する理由はありません。
名前付きパイプそれは本当にそれとは何の関係もありません。衝突もありませんでした。 X認証メカニズムの仕組みにも変更はありません。