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認証メカニズムの仕組みにも変更はありません。
答え2
だから私はXorgメーリングリストに電子メールを送り、彼らはとても役に立ちました。それで、それがすべてがうまくいく方法です。
Xorg -nolisten tcp -nolisten inet -nolisten inet6 -listen unix -nolisten local :0 -seat Seat0 vt7 -novtswitch UNIXドメインソケット（debianから取得）を除いてリスニングをオフにするために使用されるコマンド。
これにより/tmp/X11/X0 および @/tmp/X11/X0 抽象ソケット生成されています。
Xorgはこのパイプ/ソケットを介してクッキーを受け取ります（プログラムで使用）。Gtk/Qt-->Xlib[.Xauthority]）XDMによって提供された内部クッキーと比較します。一致する場合、Xorgは内部コンテキストを生成し、そのコンテキストをIP：Port（tcp / ip接続の場合）またはアプリケーションFD（ソケットの場合）[名前付きパイプソケット/ FDの生成]に関連付けます。1。
デフォルトでは、/tmp/X11/X0に書き込むすべてのアプリケーションは、Xorgにその末尾に独自のFDを生成させます。アプリケーションが終了して終了すると、FDはXorgによって閉じられますが、アプリケーションが挿入されるとXorg FD /コンテキストは破壊されず、ウイルス/悪意のあるアプリケーションはアプリケーションをだましてXorgと通信し続けることができます。 XorgはXOpenDisplay / MIT-COOKIEの後に認証にIP：Portのみを使用するため、アプリケーションがnetwork / tcpを使用している場合は簡単です。 [CookieはXorgへの1つのAPI呼び出しにのみ使用されます。]
アプリケーションが必要な場合は、COOKIEをメモリに保持してハッカーがCOOKIEを盗むことができますが、この認証ビットはXlibの作業です。 Firejailはクッキーの盗難から実際に保護しません。これは、Xvfbを使用してアプリケーションGUIをレンダリングし、Xpraを使用してピックスマップをXorgサーバーに送信することです。 Xorgサーバーは、クライアントXpraとサーバーXpraの2つの部分に分かれています（Xpraドキュメント/ readmeでこれについて説明しています）。サーバーは pixmap だけを見ることができ、信頼できるプロキシ/Xpra サーバー/クライアント/Burqa 保護の API 呼び出しは見ることができないので安全です。しかし、Xorgは情けないほど弱くてセキュリティがないので、レイプ犯はまだ彷徨っています。 :p
すべてを1つにまとめるテープが多すぎて、きちんと効率的ではありません。議論の余地があると思います。 Xorgは、1回限りのCookie認証を除いて、セキュリティは0です。他の時代のために設計されていたので..これまで何もしませんでした。あらゆる種類の不審なハッキング技術を使用し、何らかの理由でCでFirejailを使用するよりも、cgroup / resource-limitと名前空間を適用するためにbashスクリプトを書く方が簡単になると思います。 Xorgの場合... Xvfbを読み、刑務所を介してXorgにデータを抽出/転送する必要があります。