Oniux - Kernel-Level Tor Isolation für jede Linux App
Heute stellen wir euch Oniux vor, mit der eine Kernel-Level Tor Isolation für jede Linux App möglich ist! Wenn datenschutzkritische Apps und Dienste gestartet werden, möchten die Entwickler sicherstellen, dass wirklich jedes Datenpaket ausschließlich über Tor geleitet wird. Ein falsch eingestellter Proxy – oder nur ein einziger Systemaufruf außerhalb des SOCKS-Wrappers – kann schon reichen, damit Eure Daten ungewollt ins offene Netz gelangen.
Deshalb freut sich das Tor-Projekt riesig, oniux vorzustellen: ein kleines Kommandozeilen-Tool, das Netzwerk-Isolierung über das Tor-Netzwerk für Drittanbieter-Programme mithilfe von Linux-Namespaces ermöglicht. Aufgebaut auf Arti und onionmasq, kapselt oniux jedes Linux-Programm in einem eigenen Netzwerk-Namespace und leitet den gesamten Verkehr durch Tor – so wird das Risiko von Datenlecks effektiv ausgeschlossen. Wenn Eure Arbeit, Eurer Aktivismus oder Eurer Forschung absolut zuverlässige Verkehrstrennung erfordert, liefert oniux genau das.
🐧 Was sind Linux-Namespaces – einfach erklärt
Stellt Euch vor, Euer Computer ist wie ein großes Haus. In diesem Haus leben viele Programme – wie Mitbewohner, die sich Küche, Bad und Wohnzimmer teilen. Ohne Namespaces können alle Programme (also Mitbewohner) alles sehen: was die anderen tun, welche Dateien sie benutzen, welche Internetverbindungen bestehen, usw. Es gibt kaum Privatsphäre.
Jetzt kommt Linux Namespaces ins Spiel: Sie sorgen dafür, dass jeder Mitbewohner sein eigenes kleines Apartment bekommt – mit eigener Küche, eigenem WLAN-Router, eigenen Schlüsseln. Damit kann er unabhängig von den anderen leben, ohne zu sehen, was sie tun – und umgekehrt.
Technisch gesehen
Namespaces sind eine Funktion des Linux-Kernels (quasi das Herzstück des Systems), die dafür sorgt, dass bestimmte Systembereiche abgeschottet werden können – so, als ob jedes Programm in einem eigenen kleinen "Mini-Linux" lebt.
Es gibt verschiedene Arten von Namespaces, z. B.:
- Netzwerk-Namespaces: Euer Programm bekommt ein eigenes virtuelles Netzwerk – perfekt für Tor!
- Prozess-Namespaces: Euer Programm sieht nur sich selbst, nicht andere laufende Prozesse.
- Mount-Namespaces: Euer Programm hat ein eigenes Dateisystem.
- User-Namespaces: Euer Programm hat seine eigene Nutzer- und Rechteverwaltung.
Warum ist das nützlich
Weil es Sicherheit und Kontrolle bietet. Wenn Ihr eine App oder einen Dienst habt, der auf keinen Fall versehentlich Daten ins offene Internet schicken soll – z. B. weil Ihr mit Tor arbeitet – könnt Ihr ihn mit einem Netzwerk-Namespace isolieren. Selbst wenn in der App ein Fehler steckt, kommt sie nicht raus aus ihrem Käfig.
Und genau das macht das neue Tool oniux:
Es startet Euer Programm in so einem abgeschotteten Netzwerk-Raum – und leitet alle Daten zwangsweise durch das Tor-Netzwerk. Selbst wenn Ihr Euch vertippt oder deine App Mist baut: Es kann gar nichts durchsickern.
Namespaces sind also wie virtuelle Wände im Betriebssystem. Sie sorgen dafür, dass Programme getrennt voneinander leben und nicht aus Versehen oder absichtlich in Bereiche schnüffeln oder funken, wo sie nichts zu suchen haben. Das ist besonders wichtig, wenn Ihr Privatsphäre braucht – z. B. für Tor, Aktivismus oder sensible Recherchen.
Tor + Namespaces = ❤️
Wie oben beschrieben, sind Namespaces eine leistungsstarke Funktion, die es uns ermöglicht, den Tor-Netzwerkzugang einer beliebigen Anwendung zu isolieren. Wir platzieren jede Anwendung in einem Netzwerk-Namespace, der keinen Zugriff auf systemweite Netzwerkschnittstellen (wie z. B. eth0) bietet, sondern stattdessen eine eigene, benutzerdefinierte Netzwerkschnittstelle namens onion0 bereitstellt.
Dadurch können wir eine beliebige Anwendung auf die sicherste denkbare Weise softwareseitig über Tor isolieren – nämlich indem wir uns auf ein Sicherheitsprinzip verlassen, das direkt vom Betriebssystemkernel bereitgestellt wird. Im Gegensatz zu SOCKS kann die Anwendung dabei nicht versehentlich Datenlecks verursachen, indem sie Verbindungen außerhalb der konfigurierten SOCKS-Schnittstelle herstellt – was durch einen Fehler des Entwicklers passieren könnte.
oniux vs. torsocks
Ihr habt vielleicht auch schon von einem Werkzeug mit ähnlichem Ziel gehört – torsocks. Dieses Tool funktioniert, indem es alle netzwerkbezogenen Funktionen der Standard-C-Bibliothek (libc) überschreibt, sodass der gesamte Datenverkehr über einen von Tor bereitgestellten SOCKS-Proxy geleitet wird.
Auch wenn dieser Ansatz etwas plattformübergreifender ist, hat er einen entscheidenden Nachteil:
Programme, die Netzwerkverbindungen nicht über die dynamisch eingebundene libc herstellen – sei es aus böswilliger Absicht oder einfach technisch bedingt – umgehen torsocks und senden Daten ungefiltert ins Netz.
Besonders problematisch ist das bei:
- statisch kompilierten Binaries (also Programme ohne dynamisch eingebundene Bibliotheken),
- sowie bei vielen Anwendungen aus dem Zig-Ökosystem, die diesen klassischen Pfad nicht nutzen.
Vergleich: oniux vs. torsocks:
| oniux | torsocks |
|---|
| Eigenständige Anwendung | Benötigt laufenden Tor-Daemon |
| Verwendet Linux-Namespaces | Verwendet einen ld.so-Preload-Trick |
| Funktioniert mit allen Anwendungen | Funktioniert nur mit Anwendungen, die Systemaufrufe über libc machen |
| Bösartige Anwendungen können nicht ausbrechen | Bösartige Anwendungen können ausbrechen, indem sie Systemaufrufe direkt in Assembler schreiben |
| Nur für Linux | Plattformübergreifend |
| Neu und experimentell | Seit über 15 Jahren im Einsatz und bewährt |
| Nutzt Arti als Tor-Engine | Nutzt CTor (klassischer Tor-Daemon) als Engine |
| In Rust geschrieben | In C geschrieben |
Wie kann ich Oniux verwenden 🧅
Voraussetzungen
Damit Ihr oniux installieren könnt, braucht Ihr ein Linux-System mit:
Rust-Toolchain installiert (das ist der Compiler + Paketmanager cargo)
einem modernen Linux-Kernel (z. B. Ubuntu, Debian, Arch, Fedora...)
Rust & Cargo installieren (nur einmal nötig)
Öffnet Euer Terminal und gebt folgendes ein:
curl https://sh.rustup.rs -sSf | shFolge den Anweisungen (einfach mit 1 bestätigen). Danach: Terminal neu starten (wichtig!) oder einmal dies ausführen:
source $HOME/.cargo/envTesten ob's geklappt hat:
cargo --versionWenn Ihr eine Versionsnummer seht: ✅ fertig!
Oniux installieren
Jetzt könnt Ihr oniux direkt von Gitlab installieren:
cargo install --git https://gitlab.torproject.org/tpo/core/oniux --tag v0.5.0 oniuxDas dauert ein bisschen, weil es den Code aus dem Internet lädt und kompiliert. Wenn alles klappt, könnt Ihr es mit oniux --help testen.
Falls die Installation mit einer Fehlermeldung nicht startet, besucht das aktuelle Projekt auf Gitlab, und ersetzt 0.5.0 mit der aktuellsten Version:
https://gitlab.torproject.org/tpo/core/oniux
Oniux updaten
Ersetzt die Versionsnummer mit der neueren und benutzt die Option --force
cargo install --git https://gitlab.torproject.org/tpo/core/oniux --tag v0.6.0 --forceOniux deinstallieren
Habt Ihr kein Bock mehr auf Oniux, könnt ihr es so deinstallieren:
cargo uninstall oniuxBeispiele: So nutzt Ihr oniux
1. Eure aktuelle Tor-IP anzeigen:
oniux curl https://icanhazip.com→ Ihr seht eine IP-Adresse, die nicht Eure echte ist, sondern eine Tor-Ausgangsadresse
2. Mit IPv6 über Tor:
oniux curl -6 https://ipv6.icanhazip.com3. Onion-Services aufrufen:
oniux curl http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/4. Ganze Shell durch Tor leiten: Ihr wollt alle Befehle ab sofort nur noch über Tor senden? Kein Problem:
oniux bashJetzt ist Eure komplette Shell in einem Tor-Namespace. Ihr könnt einfach Programme wie gewohnt ausführen.
5. Grafische Programme isolieren (wenn Ihr z. B. im KDE/Gnome-Desktop seid):
oniux signal-desktopFunktioniert z. B. auch mit Firefox, Chromium, Thunderbird – aber beachte: Nicht alle Programme funktionieren problemlos in einem isolierten Netzwerk (z. B. solche mit systemd-abhängigen Diensten oder Wayland-Komponenten).
Wie funktioniert das intern?
oniux funktioniert, indem es sofort einen Kindprozess mithilfe des Systemaufrufs clone(2) erzeugt, der in einem eigenen Netzwerk-, Mount-, PID- und User-Namespace isoliert ist. Dieser Prozess mountet dann eine eigene Kopie von /proc, gefolgt von UID- und GID-Zuordnungen zur entsprechenden UID und GID des Elternprozesses.
Anschließend erstellt er eine temporäre Datei mit Nameserver-Einträgen, die dann mittels Bind-Mount auf /etc/resolv.conf gemountet wird, sodass Anwendungen innerhalb des Prozesses einen benutzerdefinierten Namensauflöser verwenden, der die Namensauflösung über Tor unterstützt.
Danach verwendet der Kindprozess onionmasq, um eine TUN-Schnittstelle mit dem Namen onion0 zu erstellen, gefolgt von einigen rtnetlink(7)-Operationen, die erforderlich sind, um die Schnittstelle einzurichten, wie z. B. das Zuweisen von IP-Adressen.
Dann sendet der Kindprozess den Dateideskriptor der TUN-Schnittstelle über einen Unix-Domain-Socket an den Elternprozess, der seit der Ausführung des ursprünglichen clone(2)-Aufrufs auf diese Nachricht wartet.
Sobald dies abgeschlossen ist, verwirft der Kindprozess alle Fähigkeiten (Capabilities), die er im Rahmen des Root-Prozesses im User-Namespace erworben hat.
Schließlich wird der vom Benutzer übergebene Befehl unter Verwendung der Funktionen der Rust-Standardbibliothek ausgeführt.
Beispiel: Signal Desktop über Tor leiten
Mit torsocks
Ihr versucht vielleicht so etwas wie:
torsocks signal-desktopUnd was passiert?
➡️ Entweder Signal startet gar nicht,
➡️ oder es startet, aber der Netzwerkverkehr geht trotzdem nicht über Tor.
Warum?
torsocksfunktioniert nur, wenn Programme Netzwerkverbindungen über die dynamischelibcaufbauen.- Signal (eine Electron-App) nutzt teils eigene Netzwerkschichten (Node.js, Chromium), WebRTC, UDP, Threads – das umgeht torsocks vollständig.
- Es kann also unkontrolliert "nach Hause telefonieren", selbst wenn
torsocksaktiv ist. - Komplizierte Setups für Apps die nicht mit torsocks funktioneren z.B. eben Signal.
Mit oniux
Ihr startet Signal so:
oniux signal-desktopUnd was passiert?
➡️ Signal wird in einem komplett isolierten Netzwerkbereich (Namespace) gestartet.
➡️ Es hat keinen Zugang zu deinem normalen Internet (kein eth0, kein WLAN).
➡️ Es gibt nur eine Schnittstelle: onion0 → durch Tor!
Ergebnis:
- Jede einzelne Verbindung muss durch Tor gehen
- Keine Leaks möglich, selbst wenn Signal es „versuchen“ würde
- Auch UDP/WebRTC etc. funktionieren nicht → und das ist gut so, wenn es um Datenschutz geht.
Oniux und Secureboot
Aktuell funktioniert oniux nicht auf Systemen mit aktiviertem Secure Boot, da wichtige Kernelfunktionen wie clone() und mount() innerhalb von User-Namespaces durch AppArmor eingeschränkt werden. Selbst bei deaktiviertem AppArmor-Dienst bleibt die Blockade aktiv, solange Secure Boot aktiv ist.
➡️ Eine Nutzung von oniux ist derzeit nur möglich, wenn Secure Boot deaktiviert oder in einer entsprechend konfigurierten virtuellen Maschine gearbeitet wird.
Oniux ist experimentell ⚠️
Auch wenn Euch dieser Abschnitt nicht davon abhalten soll, oniux zu benutzen, solltet Ihr im Hinterkopf behalten, dass es sich hierbei um eine relativ neue Technologie handelt, die auf moderner Tor-Software wie Arti und onionmasq basiert.
Aktuell funktioniert bereits alles wie erwartet, aber: Werkzeuge wie torsocks existieren seit über 15 Jahren und haben sich in zahllosen realen Einsätzen bewährt.
Das Ziel ist es jedoch, mit oniux einen ähnlichen Reifegrad zu erreichen – also probiert es gerne aus und gebt es eine Chance! 🧅
Ein herzliches Dankeschön an das Tor-Team für oniux
Vielen Dank an alle Entwicklerinnen und Entwickler beim Tor-Projekt, die mit oniux, Arti und onionmasq neue Wege gehen, um Netzwerk-Isolation über Tor sicherer und robuster zu machen.
Eure Arbeit an oniux ist ein großer Schritt in Richtung moderner, kernel-basierter Verkehrskontrolle – ganz ohne die Risiken klassischer SOCKS-Proxies. Die Kombination aus Namespaces, TUN-Interfaces und einem minimalistischen Design ist elegant, durchdacht und technisch beeindruckend.
Danke, dass ihr Privatsphäre und Sicherheit nicht nur denkt, sondern wirklich lebt – und dafür Werkzeuge schafft, die Menschen auf der ganzen Welt schützen können.
Bitte macht weiter so. Eure Arbeit ist wichtiger denn je.
Quelle: https://blog.torproject.org/introducing-oniux-tor-isolation-using-linux-namespaces/
