Oniux: Kernel-level Tor isolation for any Linux app

[FranklyFlawless]

Introducing oniux: Kernel-level Tor isolation for any Linux app | Tor Project

Relevant quotes:

oniux vs. torsocks

You may have also heard of a tool with a similar goal, known as torsocks, which works by overwriting all network-related libc functions in a way to route traffic over a SOCKS proxy offered by Tor. While this approach is a bit more cross-platform, it has the notable downside that applications making system calls not through a dynamically linked libc, either with malicious intent or not, will leak data. Most notably, this excludes support for purely static binaries and applications from the Zig ecosystem.

The following provides a basic comparison on oniux vs torsocks:

oniux	torsocks
Standalone application	Requires running Tor daemon
Uses Linux namespaces	Uses an ld.so preload hack
Works on all applications	Only works on applications making system calls through libc
Malicious application cannot leak	Malicious application can leak by making a system call through raw assembly
Linux only	Cross-platform
New and experimental	Battle-proven for over 15 years
Uses Arti as its engine	Uses CTor as its engine
Written in Rust	Written in C

How does this work internally?

oniux works by immediately spawning a child process using the clone(2) system call, which is isolated in its own network, mount, PID, and user namespace. This process then mounts its own copy of /proc followed by UID and GID mappings to the respective UID and GID of the parent process.

Afterwards, it creates a temporary file with nameserver entries which will then be bind mounted onto /etc/resolv.conf, so that applications running within will use a custom name resolver that supports resolving through Tor.

Next, the child process utilizes onionmasq to create a TUN interface named onion0 followed by some rtnetlink(7) operations required to set up the interface, such as assigning IP addresses.

Then, the child process sends the file descriptor of the TUN interface over a Unix Domain socket to the parent process, who has been waiting for this message ever since executing the initial clone(2).

Once that is done, the child process drops all of its capabilities which were acquired as part of being the root process in the user namespace.

Finally, the command supplied by the user is executed using facilities provided by the Rust standard library.

[arraybolt3]

I hope this isn’t embedding an entire copy of Arti into the Oniux application. That would make it fairly impossible to use with Whonix, due to the inability to split things into a gateway and a workstation. (That said, we already do ensure everything is tunneled with firewalls, so maybe this wouldn’t be that useful for us anyway.)