Vorstellung von Oniux, einem Kernel-Level-Tool zur Tor-Isolation für Linux-Apps

 (blog.torproject.org)
4 Punkte von GN⁺ 2025-06-02 | 2 Kommentare | Auf WhatsApp teilen
  • Oniux ist ein Kernel-Level-Isolationstool, das den gesamten Traffic von Linux-Apps zwangsweise über das Tor-Netzwerk umleitet und so das Risiko von Datenlecks minimiert
  • Mithilfe von Linux-Namespaces werden einzelne Apps in voneinander getrennte Netzwerkumgebungen isoliert, um eine sichere Kommunikation über Tor zu ermöglichen
  • Im Unterschied zu torsocks funktioniert es auch mit statischen Binärdateien oder Programmen ohne libc und blockiert so direkte Datenabflusswege bösartiger Apps
  • Oniux basiert auf dem neuen Arti und onionmasq und ist in Rust geschrieben, was sowohl Sicherheit als auch Erweiterbarkeit verbessert
  • Derzeit ist Oniux ein experimentelles Tool; in puncto Stabilität ist es nicht mit dem bewährten torsocks gleichzusetzen, gilt aber als vielversprechende Next-Generation-Lösung für die Isolation von Tor-Traffic

Vorstellung von Oniux

Oniux ist ein Kommandozeilen-Utility, das unter Linux durch Tor-Netzwerkisolation das Datenschutzniveau deutlich erhöht. Es wurde so entwickelt, dass Entwickler, Aktivisten und Forschende die Möglichkeit von Datenlecks durch fehlerhafte Proxy-Konfigurationen oder kleine Unachtsamkeiten vollständig ausschließen können. Oniux läuft auf Arti und onionmasq und isoliert jede Linux-App in einem separaten Netzwerk-Namespace, sodass ihr Traffic ausschließlich über das Tor-Netzwerk geleitet wird.

Was sind Linux-Namespaces?

  • Namespaces sind eine zentrale Isolationsfunktion des Linux-Kernels
  • Sie trennen bestimmte Ressourcen einer Anwendung logisch vom Gesamtsystem
  • Damit lassen sich verschiedene Ressourcen wie Netzwerk, Mounts und Prozesse isolieren
  • Jeder Namespace trennt Betriebssystemressourcen und wird für Container-Umgebungen oder Sicherheitszwecke eingesetzt
  • Bekannte Container-Lösungen wie Docker nutzen Namespaces als Grundprinzip

Die Bedeutung der Kombination aus Tor und Namespaces

  • Namespaces schützen den Tor-Netzwerkzugang beliebiger Anwendungen durch vollständige Isolation
  • Jede App wird in einem eigenen Netzwerk-Namespace platziert, wobei nur ein benutzerdefiniertes Interface namens onion0 sichtbar ist
  • Da die App keinen Zugriff auf systemweite Netzwerk-Interfaces des OS (z. B. eth0) hat, lässt sich die Sicherheit maximieren
  • Anders als bei SOCKS-basierten Proxy-Ansätzen besteht selbst bei Fehlern oder Defekten kein Risiko eines direkten Traffic-Lecks

Vergleich von Oniux und torsocks

  • Torsocks klinkt sich per LD_PRELOAD-Technik in die Netzwerkfunktionen von libc ein und leitet sie über den SOCKS-Proxy von Tor um
  • Oniux arbeitet mit Namespace-Isolation und verhindert auch bei statischen Binärdateien oder Zig Traffic-Lecks zu 100 %
  • Wichtige Vergleichspunkte
    • Oniux: kein separater Tor-Daemon erforderlich, nutzt Namespaces, unterstützt alle Apps, blockiert auch Raw-Syscalls bösartiger Apps, nur für Linux, neu/experimentell, Arti-basiert, in Rust geschrieben
    • Torsocks: Tor-Daemon erforderlich, ld.so-Hack, unterstützt nur an libc gebundene Apps, Raw-Syscalls können leaken, plattformübergreifend, seit über 15 Jahren bewährt, CTor-Engine, in C geschrieben

Verwendung von Oniux

  • Erforderlich ist ein Linux-System mit eingerichteter Rust-Entwicklungsumgebung
  • Oniux lässt sich einfach über die Kommandozeile installieren und ausführen

Wichtige Anwendungsbeispiele:

  • $ oniux curl https://icanhazip.com # Über Tor erhaltene IP anzeigen
  • $ oniux bash # Eine komplette Shell in Tor-Isolation starten
  • $ oniux hexchat # Auch GUI-Apps lassen sich zwangsweise über Tor leiten
  • $ RUST_LOG=debug oniux curl ... # Unterstützung für Debug-Logging

Interne Funktionsweise

  • Oniux erzeugt mit dem Systemaufruf clone(2) einen Kindprozess in separaten Netzwerk-, Mount-, PID- und Benutzer-Namespaces
  • Der Kindprozess mountet /proc separat und passt die Rechte per UID-/GID-Mapping an
  • Eine temporäre Datei mit Nameserver-Informationen wird per Bind-Mount auf /etc/resolv.conf eingebunden, um die Nutzung eines Tor-basierten Namensauflösers zu erzwingen
  • Mit onionmasq wird ein TUN-Interface (onion0) erstellt und mit IP-Adresse und Konfiguration versehen
  • Der Kindprozess übergibt den Interface-fd über einen Unix-Domain-Socket an den Elternprozess und minimiert so die Berechtigungen
  • Mithilfe von Rust-Funktionalität wird schließlich der vom Nutzer eingegebene Befehl ausgeführt

Der experimentelle Charakter von Oniux

  • Oniux ist eine frühe Version auf Basis neuer Technologien wie Arti und onionmasq
  • Es funktioniert derzeit ordnungsgemäß, verfügt aber noch nicht über die langjährige Reife und Praxiserfahrung von torsocks
  • Für bessere Stabilität und Performance ist vielfältiges Feedback aus realen Einsätzen nötig

Danksagung und Unterstützung

  • Dank gilt Entwicklern wie smoltcp, einem Rust-basierten IP-Stack, sowie 7ppKb5bW, die bei der Nutzung von Benutzer-Namespaces in der Entwicklung beraten haben
  • Das Oniux-Projekt wird durch Unterstützung von The Tor Project und der Community aufrechterhalten; zur Förderung von Privatsphäre und Open Source Software wird zu Spenden ermutigt

Verwandte Beiträge

2 Kommentare

 
ndrgrd 2025-06-03

Tor scheint für die Privatsphäre nicht schlecht zu sein, aber ich bin mir nicht sicher, ob es wirklich das richtige Werkzeug für Anonymität ist. Es heißt auch, dass staatliche Stellen die Exit-Nodes bereits unter ihre Kontrolle gebracht haben.
 
GN⁺ 2025-06-02
Hacker-News-Kommentare
  • Ich habe vor etwa 10 Jahren, als Netzwerk-Namespaces ein heißes Thema wurden, mit einem Tor-Entwickler darüber gesprochen. Das Feedback damals war, dass die Isolation per Namespace den Leuten zwar ein Gefühl von Sicherheit gibt, aber trotzdem noch viele identifizierbare Informationen durchsickern können, weshalb man das damals wohl nicht weiterverfolgt hat.
    • Ich denke, es war ein strategischer Fehler, dass das Tor-Team diesen Punkt so stark betont hat. Für Menschen mit ernsthaften Bedrohungslagen ist es richtig, den Tor Browser zu verwenden und auch auf andere Informationslecks zu achten. Aber wenn Tor für alle der Standard geworden wäre, wäre großflächige Überwachung selbst viel schwieriger geworden. Im Moment ist schon die Tatsache, wer Tor benutzt, ein Überwachungsziel, aber wenn es alle nutzen würden, wäre diese Information bedeutungslos.
    • torsocks und torify erfüllen im Grunde dieselbe Rolle, wirken aber in Sachen Robustheit etwas weniger solide.
  • Wenn man die Befehle aus der Installationsanleitung verwendet, funktioniert es nicht. Man muss die Versionsnummer von 0.4.0 auf 0.5.0 ändern.
    cargo install --git https://gitlab.torproject.org/tpo/core/oniux oniux@0.5.0
  • Ich dachte ursprünglich, dass der Traffic wie bei torsocks über einen lokal laufenden Tor-Daemon hinausgeht. Aber selbst wenn ich den lokalen Tor-Daemon stoppe, funktioniert oniux weiterhin problemlos, während torify und torsocks dann nicht mehr gehen. Laut Dokumentation ist das tatsächlich so. Ziemlich faszinierend. Es funktioniert auch gut in Docker, allerdings musste ich die Option --privileged verwenden, und sogar wenn man einfach nur das Binary in einen debian:12-Container kopiert, läuft es korrekt.
    docker run -it --rm --privileged -v "$PWD/oniux:/usr/bin/oniux" debian:12
  • Ich frage mich, ob das alles nur für TCP gilt. Also ob auch nicht-TCP-Traffic geschützt wird.
    • Ich weiß es nicht genau, aber wenn man sich https://gitlab.torproject.org/tpo/core/onionmasq ansieht, scheint es ein Versuch zu sein, einen User-Space-Netzwerk-Stack zu bauen, der nicht nur TCP, sondern auch UDP unterstützt und an das Tor-Netzwerk weiterleitet.
    • Ich frage mich, wie Leute mit dem Tor Browser YouTube, DNS und auch HTTP/3 handhaben.
    • Nicht-TCP-Traffic wird nicht geroutet, sondern die Übertragung schlägt einfach fehl.
  • Oniux scheint ein offiziell unterstütztes Tool zu sein. Es ist ähnlich wie orjail, aber bei orjail gab es seit 4 Jahren keine Commits mehr, obwohl es als Shell-Skript zusammen mit den Tools iptables/iproute weiterhin gut funktioniert.
    orjail hat außerdem eine Option für zusätzliche Isolation mit firejail, die Oniux bisher noch nicht hat.
    https://github.com/orjail/orjail/blob/master/usr/sbin/orjail
  • Ich frage mich jetzt, ob man damit per Chrome auf Tor-Websites zugreifen kann.
    • Man kann, aber ich würde davon abraten. Chrome hat nicht die verschiedenen Anti-Fingerprinting-Strategien des Tor Browser. Wenn man einen normalen Browser nutzt, fällt man eher auf.
    • Eigentlich war das schon immer möglich, solange man nur die Proxy-Umgebungsvariablen (oder die Einstellungen) korrekt setzt. Der Standard-Port des Tor-Daemons ist 9050. Es ist auch recht einfach, selbst einen SOCKS-Proxy zu schreiben und Traffic darüber zu routen. Zum Beispiel kann man so Traffic zu etwas wie syncthing über einen socks5-Proxy schicken.
      https://github.com/acheong08/syndicate
  • Als Beispiel wird hexchat genannt, aber wenn man die Profil-Einstellungen des Nutzers unverändert verwendet, wird dann nicht der IRC-Benutzername offengelegt?
    Beim Starten eines Browsers könnten ja auch Dinge wie Cookies offengelegt werden.
    • Rollentrennung ist wichtig. Tor investiert zwar viel Aufwand in Anti-Fingerprinting, aber grundsätzlich ist das Ziel von Tor und Oniux, die Rückverfolgung der Ursprungs-IP unmöglich zu machen. Wenn man sich über Tor bei Gmail anmeldet, hat man dasselbe Problem (sofern kein HTTPS verwendet wird).
    • Ich bin nicht sicher, was genau damit gemeint ist, dass der Benutzername „offengelegt“ wird. Praktisch zeigt dieser Benutzername nur, dass die Person Tor verwendet. Wenn derselbe Benutzername wiederholt denselben IRC-Host über Tor anspricht, kann dadurch offengelegt werden, dass es sich immer um dieselbe Person handelt. Wenn Anonymität das Ziel ist, ist IRC also ein ziemlich riskantes Mittel. Viele Leute protokollieren Dinge in Verbindung mit Netzunterbrechungen und ähnlichen Ereignissen, sodass Zusammenhänge sichtbar werden können.
  • Der DevEx-Teil ist wirklich sehr gut gemacht und wirkt fast idiotensicher. Dem Entwicklungsteam möchte ich applaudieren.
    • Ganz so ist es meiner Meinung nach nicht. Idioten sind immer kreativ, und um Anonymität zu gewährleisten, braucht man einen sehr vorsichtigen operativen Umgang — ein Niveau, das man von den meisten Nutzern kaum erwarten kann.
  • Wenn mir jemand den Code in C neu schreiben würde, würde ich ihn mit Freude verwenden.
    • Er ist bereits in Rust geschrieben. Ich frage mich, warum man unbedingt eine C-Version möchte.