oniux: Kernel-level Tor isolation for any Linux app (goodbye torsocks)

oniux: Kernel-level Tor isolation for any Linux app (goodbye torsocks)

The dream of every paranoid sysadmin (or anyone who gives a damn about their OPSEC) is simple: launch a program and have mathematical certainty that no IP packet can leak outside of Tor. The reality, however, is a hellscape of misconfigured proxies, misbehaving dynamic link libraries, and applications that arbitrarily decide to make cleartext network calls, bypassing all your hard work.

For years, the de facto standard for forcing third-party applications through Tor was torsocks. However, it remains a legacy utility built on limitations that no longer fit modern environments.

Today, we're talking about oniux, a new command-line utility introduced by the Tor Project, designed to bury the past and lock down applications at the kernel level.

The Problem with torsocks (The Death of LD_PRELOAD)

How does torsocks work? It leverages the LD_PRELOAD environment variable to intercept (hijack) network functions in the standard C library (libc). When a dynamically linked application tries to open a socket, torsocks steps in and forces the call through Tor's local SOCKS proxy.

While portable, this approach has holes large enough to drive a truck through:

1. Static Binaries: If a binary is compiled statically (a standard practice in Go, Rust, or the Zig ecosystem), it does not load dynamic libraries. LD_PRELOAD is completely ignored, and the program happily communicates in the clear.
2. Direct System Calls: If the application bypasses libc and makes direct network system calls, torsocks is blind and cannot intercept them.
3. Malware and Evasion: Any minimally hostile code can evade libc hijacking with ease.

Simply put: if you use torsocks, you are betting your freedom on the hope that someone else's compiler was "friendly." Spoiler alert: it isn't.

The Kernel Way: Tor + Namespaces

oniux solves the problem at the root by shifting isolation from the application level to the Linux kernel, leveraging Namespaces—the exact same primitive technology behind Docker and containers.

When you run a program with oniux, the utility performs the following operations:

1. Network Isolation: It creates a new, dedicated network namespace. Any physical network interfaces of the host machine (like eth0 or wlan0) are absent from this environment. The program finds itself in an isolation cell with no default routes to the WAN.
2. The onion0 Interface: Inside the namespace, it mounts a virtual TUN interface named onion0, managed by onionmasq (the Tor Project's tunneling framework) and backed by Arti (the modern Tor implementation in Rust). This is the only network interface the application can see.
3. Hardened DNS: Using a private mount namespace, oniux injects a custom /etc/resolv.conf that points directly to the secure DNS resolver provided by onionmasq. DNS queries cannot escape to the outside world.

The result? The isolated program doesn't need to be configured. It can make normal network calls, believing it is on the open internet, but every single TCP/UDP or DNS packet sent to any address is forced by the kernel through the onion0 TUN interface, encrypted, and routed through Tor. If the tunnel dies, the network dies. Zero leaks.

Advantages and Disadvantages of oniux

Like any security tool, oniux has its share of pros and cons.

Advantages:

• No Leaks by Design: The application literally has no route to the cleartext network. Even if it tries to bypass proxies, it can't.
• Universal Support: Works with statically compiled binaries (Go, Rust, Zig, static C).
• Transparency: No need to configure SOCKS ports or HTTP proxies in the target application.

Disadvantages:

• Experimental: The tool is young, built on Arti and onionmasq codebases that are still maturing.
• Linux-Only: Requires the Linux kernel's namespace features and the tun kernel module loaded.
• IPC (Inter-Process Communication) Leaks: If you run an application with oniux that connects to an existing daemon running on the host system (e.g., a browser connecting to a Firefox instance already open outside the namespace), traffic can still leak outside Tor via IPC sockets.

Practical Notes and Tips

To run oniux smoothly, keep these rules in mind:

1. Load the TUN Module: The kernel must support TUN devices. If you encounter startup errors, ensure the module is loaded:

   sudo modprobe tun

2. Usage Examples: To verify that isolation is active, query an IP lookup service:

   oniux curl https://icanhazip.com

   Or launch an isolated shell where all subsequent commands will automatically route through Tor:

   oniux bash

3. Debug Logging: If something isn't working as expected, enable verbose logging from Arti/onionmasq by setting the Rust environment variable:

   RUST_LOG=debug oniux curl http://example.onion

The future of Tor isolation on Linux is here, and it is written in Rust at the kernel level. Retreive your legacy tools, archive torsocks, and start practicing serious OPSEC.

[May the Talpone be with you]

Discussion & Support

Discussion and support channel. To discuss configurations or other topics, join us on fluxer.dreadful.work.