4 ポイント 投稿者 GN⁺ 2025-06-02 | 2件のコメント | WhatsAppで共有
  • 任意の Linux プログラムを別個のネットワーク環境に閉じ込め、すべてのトラフィックを Tor に送ることで、アプリごとのプロキシ設定に依存していた漏えいリスクを減らすツール
  • 中核となるのは Linux カーネルの ネットワーク名前空間 で、アプリにはシステムインターフェースの代わりに onion0 だけを見せることで、迂回接続を難しくする
  • 既存の torsocks は libc 関数をフックする方式のため、静的バイナリや Zig エコシステムのように libc を経由しない呼び出しではデータが漏れる可能性がある
  • oniux は Arti と onionmasq を基盤とする Linux 専用の Rust ツールで、torsocks は CTor ベースの C 実装としてクロスプラットフォームであり、15年以上使われてきた方式
  • ユーザーは既存コマンドの前に oniux を付けて curl, bash, hexchat などを実行できるが、新しく実験的なツールである点は考慮する必要がある

oniux が解決しようとする Tor 分離の問題

  • プライバシーが重要なアプリやサービスを実行する際は、すべてのパケットが実際に Tor 経由 でのみ外部に出る必要がある
  • プロキシ設定を誤入力したり、SOCKS ラッパーの外でシステムコールが発生したりすると、データが露出する可能性がある
  • oniux は Linux 名前空間を使ってサードパーティ製アプリケーションに Tor ネットワーク分離を提供するコマンドラインユーティリティ
  • Arti と onionmasq の上で動作し、Linux プログラムを独自のネットワーク名前空間に入れて Tor にルーティングする
  • 文書の冒頭には、oniux が独自の Web サイトを持つようになったことと、この記事のバージョン番号はかなり古いという警告がある

Linux 名前空間が担う役割

  • 名前空間 は Linux カーネルの分離機能で、2000年ごろに導入された
  • アプリケーションの特定部分をシステムの残りの領域から安全に分離できる
  • 名前空間は分離対象に応じて複数の形に分かれる
    • ネットワーク名前空間
    • マウント名前空間
    • プロセス名前空間
    • そのほかのさまざまな種類
  • Linux のシステムリソースは通常、すべてのアプリケーションがグローバルにアクセスできる
    • OS の時計
    • プロセス一覧全体
    • ファイルシステム
    • ユーザー一覧
  • 名前空間はアプリケーションの一部を OS の残りの部分から コンテナ化 し、Docker も分離プリミティブを提供する際にこの機能を使っている

Tor と名前空間を組み合わせる方法

  • oniux は各アプリケーションを、システム全体のネットワークインターフェースにアクセスできない ネットワーク名前空間 の中で実行する
  • その名前空間には eth0 のようなシステムインターフェースの代わりに、ユーザー定義のネットワークインターフェース onion0 だけが提供される
  • この方式は、OS カーネルが提供するセキュリティプリミティブに依存して、任意アプリケーションの Tor アクセスを分離する
  • SOCKS 方式と異なり、開発者のミスで一部の接続が設定済み SOCKS を通らずデータが漏れる状況を減らせる

oniux と torsocks の違い

  • torsocks は、Tor が提供する SOCKS プロキシへトラフィックを送るために、ネットワーク関連の libc 関数をフックするツール
  • この方式は oniux よりクロスプラットフォーム性が高いが、動的リンクされた libc を通らないシステムコールではデータが漏れる可能性がある
  • 特に 完全静的バイナリ と Zig エコシステムのアプリケーションは torsocks のサポート対象外
  • oniux

    • スタンドアロンの実行アプリケーション
    • Linux 名前空間を使用
    • すべてのアプリケーションで動作
    • 悪意あるアプリケーションでもデータ漏えいが不可能な構造
    • Linux 専用
    • 新しく実験的なツール
    • Arti をエンジンとして使用
    • Rust 製
  • torsocks

    • 実行中の Tor デーモンが必要
    • ld.so の preload ハックを使用
    • libc 経由でシステムコールを行うアプリケーションでのみ動作
    • 悪意あるアプリケーションは raw assembly でシステムコールを作成してデータを漏らせる
    • クロスプラットフォーム
    • 15年以上の実績がある
    • CTor をエンジンとして使用
    • C 製

インストールと使用例

  • Linux システムと Rust ツールチェーンが必要
  • インストールは cargo install で行う
cargo install --git https://gitlab.torproject.org/tpo/core/oniux --tag v0.4.0 oniux
  • 単純な HTTPS リクエストを Tor 経由で実行できる
oniux curl https://icanhazip.com
  • IPv6 リクエストにも対応
oniux curl -6 https://ipv6.icanhazip.com
  • onion service へのアクセスも可能
oniux curl http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/…
  • ロギングは RUST_LOG=debug で有効化できる
RUST_LOG=debug oniux curl https://icanhazip.com
  • シェル全体を Tor 経由で実行すれば、その中のすべてのプロセスを分離できる
oniux bash
  • デスクトップ環境では GUI アプリケーションも分離可能
oniux hexchat

内部動作の流れ

  • oniux はまず clone(2) システムコールで子プロセスを生成する
  • 子プロセスは独自の ネットワーク、マウント、PID、ユーザー名前空間 の中で分離される
  • その後、子プロセスは /proc の独自コピーをマウントし、親プロセスの UID と GID に合わせて UID/GID マッピングを設定する
  • アプリケーションが Tor を通じて名前解決できるよう、nameserver エントリを含む一時ファイルを作成し、これを /etc/resolv.conf に bind mount する
  • 子プロセスは onionmasq を使って onion0 という TUN インターフェースを作成する
  • 続いて rtnetlink(7) 操作でインターフェースを設定し、IP アドレスの割り当てなどを行う
  • 子プロセスは TUN インターフェースのファイルディスクリプタを Unix Domain socket 経由で親プロセスに渡す
  • 親プロセスは最初の clone(2) 実行後、このメッセージを待機する
  • 引き渡しが終わると、子プロセスはユーザー名前空間の root プロセスになったことで得たすべての capability を破棄する
  • 最後に、ユーザーが指定したコマンドを Rust 標準ライブラリの機能で実行する

実験的な状態と利用上の注意

  • oniux は比較的新しい機能であり、Artionionmasq のような新しい Tor ソフトウェアを使用している
  • 現時点では期待どおりに動作しているが、torsocks は15年以上使われており、より多くの実運用経験がある
  • 目標は oniux も torsocks と同程度の成熟度に到達すること

2件のコメント

 
ndrgrd 2025-06-03

Tor はプライバシーには悪くないように思いますが、匿名性に適したツールかどうかはよく分かりませんね。出口ノードはすでに国家機関に掌握されているという話もありますし。

 
GN⁺ 2025-06-02
Hacker News のコメント
  • 10年ほど前、ネットワーク名前空間が出始めたころに、この件について Tor 開発者と話したことがある
    そのときのフィードバックは、人々に安全だと誤解させつつ、識別可能な情報を大量に漏らしやすくする方法だ、というものだったので、それ以上は推し進めなかった

    • Tor 側がその方向を推し進めたのは戦略的ミスだったと思う
      深刻な脅威にさらされている人は Tor Browser を使い、ほかの漏えい経路にも常に注意すべきなのはその通りだが、Tor がどこでも使われる状態になっていれば、大規模監視ははるかに難しくなっていただろう
      今は大規模監視で誰が Tor を使っているか検知できるが、全員が使っていたなら、その事実に大した意味はなかったはずだ
    • 変だ。torsockstorify も同じことをするが、より堅牢でないだけだ
  • これは全部 TCP だけに当てはまるのでは? つまり、TCP ではない活動はどうやって保護できるのか気になる

    • 詳しくは知らないが、https://gitlab.torproject.org/tpo/core/onionmasq にはこう書かれている
      このプロジェクトは、TCP および UDP の状態を扱える単純なユーザー空間ネットワークスタックを実装し、トラフィックを Tor ネットワークへ転送できるようにしようとする試みである
    • Tor Browser ユーザーは YouTubeDNS をどう扱っているのだろう? HTTP/3 がどうなるのかも気になる
    • TCP ではない活動はルーティングされず、送信に失敗するだろう
  • トップページのインストール手順が動かない。バージョン番号を 0.4.0 から 0.5.0 に変える必要がある
    cargo install --git https://gitlab.torproject.org/tpo/core/oniux oniux@0.5.0

  • Oniux は orjail に似た「公式」サポートツールのように見える。orjail は4年間コミットがないが、iptables/iproute ツールを使うシェルスクリプトとして、今でも非常によく動作する [1]
    orjail には追加の隔離のために firejail と一緒に実行するオプションもあるが、Oniux にはまだない機能のようだ
    [1] https://github.com/orjail/orjail/blob/master/usr/sbin/orjail

  • 最初は、これは torsocks のようにローカルで動いている tor デーモンを通してトラフィックを送る方式だと思っていた
    ところがローカルの tor デーモンを止めても oniux は動き続け、torify と torsocks は動かないのを見た。ドキュメントにも実際そう書かれていた。なかなか良い
    Docker の中でも動くが、--privileged が必要だった。バイナリを debian:12 コンテナにコピーしたら、そこでも動いた:
    docker run -it --rm --privileged -v "$PWD/oniux:/usr/bin/oniux" debian:12

  • 面白いことに、これは curl では5年間壊れたままで、ブログの例も同様だ。Tor 開発者たちが以前、アプリは .onion ドメイン名の解決を試みるべきではないと主張していたためだ: https://daniel.haxx.se/blog/2025/05/16/leeks-and-leaks/
    解決策が見つかるといい

  • つまり、これで Chrome から Tor のウェブサイトにアクセスできるということ?

    • 可能ではあるが、どうかやめたほうがいい。むしろ目立つようになる。Tor Browser には Chrome にはない複数のフィンガープリント対策がある
    • 以前からプロキシ環境変数や設定を指定するだけで可能だった。tor デーモンの標準ポートは 9050
      実際、任意のプロトコル経由でトラフィックをルーティングできる SOCKS プロキシは比較的簡単に作れる。たとえば SOCKS5 プロキシを変換レイヤーとして使い、syncthing 上でウェブサイトを提供したり訪問したりできる: https://github.com/acheong08/syndicate
  • 例として hexchat を使っているが、こういうプロセスはユーザー設定で実行されるのだろうか? 設定変更を忘れると IRC のユーザー名が漏れないか
    ブラウザを起動すると Cookie も漏れる可能性があるのでは?

    • 関心の分離だ。Tor はフィンガープリンティングを防ぐために多くの努力をしているが、個人的には Tor と Oniux の主目的は送信元 IP を追跡不能にすることだと思う
      Tor 経由で Gmail にログインする場合にも同じことが言えただろう。HTTPS でなかったなら、という話だが
    • ユーザー名が漏れるとはどういう意味かわからない。ユーザー名が Tor を使っているという事実は明らかになり得る
      同じ IRC ホストに接続しているすべてのユーザー名が同一人物だという事実も、なお明らかになるだろう
      匿名性を維持しようとするなら、IRC はかなり危険に見える。多くの人が切断時刻を記録していて、ほかのネットワーク障害イベントと相関を取れるからだ
  • ここの開発者体験は非常によく作られていて、誰でも使えるほどだ。作った人たちはよくやった <3

    • まったくそうではない。愚か者は発想が豊かだ。匿名性を保つ形でこれを使うために必要な運用上の注意は、ほとんどのユーザーには難しすぎる
  • いいね。ではプロトタイプを C で書き直してくれたら、喜んで使う

    • これは Rust で書かれている。なぜ C 版が必要なのか?