Managing programs without Tor DNS Support / orjail

redsocks might work to restrict applications running under a specific user so these get stream isolated with better guarantee. Better than torsocks, but worse less guarantee than a split network architecture (isolating proxy). Anyhow. Worthwhile.

Perhaps the whole thing could be automated with linux network namespaces. I.e. run some command, that creates a (temporary?) linux user account (and/or linux network namespace), forces all connections to redsocks which then forwards to a Tor SocksPort. We could use the same Tor SocksPort and then have configure redsocks to use a different socks user name so Tor will stream isolate it. It’s like inventing a new tool.

1 Like

Related to redsocks:

Even mentioned in Whonix wiki:

Now we’re talkin :slight_smile:

Sounds good. I’ll look into it. Many Whonix programs are very specialized for our own purposes anyhow. At least you write once, run everywhere later. It will really give us flexibility to expand our software selection without having to compromise on stream isolation or butt heads against upstream limitations.

1 Like

Aside from the author’s opinion and the fact that badvpn is not packed in Debian, he gives a clue on how to use namespaces to redirect inidiviual processes with redsocks.

// redsocks does transparent proxying by using iptables’ REDIRECT. This is
// feasible for system-wide redirection, but it is hard to isolate a single
// process. The only options to to that were either to use a different UID,
// which is pretty secure, but also restricts what you can to with the
// process in other ways, or to use network namespaces with virtual devices,
// and to set up the rule only for traffic from the endpoint in the global
// namespace. It is a pain to configure this.


Found an intro on network namespaces


Also did you mention another torification tool lately? That had even a bit shorter code. Was written in C and used iptables commands internally if I remember right.

I guess such a tool could be written in bash or python. At the moment I see no reason to go for C.

1 Like

You mean ttdnsd : The TOR TCP DNS Daemon ? It uses LD_PRELOAD instead of iptables AFAICT. I am not sure it can do application specific routing by itself. solutions that use LD_PRELOAD are said to be easily circumvented by the tunsocks author. I don’t know if he meant accidental or deliberate malicious actions. If we are talking malfeasance then we have bigger problems. Also we wouldn’t ever install a malicious program on purpose so it s a moot point.

IMO tunsocks is our best bet since it does all the program specific namespace redirection leg work. Though it does not support UDP, it is able to encapsulate DNS with TCP and forward it to the socks server you want.

(tunsocks should not be confused with tun2socks - the latter a part of a feature rich suite known as badvpn)

Depending on the re-write difficulty, I wouldn’t worry much about language safety because it runs in the WS.

No, I meant AORTA a transparent Tor proxy for Linux programs.

It uses iptables internally.

In Source code search for

"-t nat -A aorta -d -p udp -m udp ! --dport 53 -j RETURN",


1 Like

That might require to modify $HOME variable and allowing the other linux user account name to write to user user's folder. Probably solvable.

1 Like

Solution: multiple Tor TransPorts and DnsPorts pre-configured.

Summary way forward:

As uwt/torsocks replacement…

Run application either

a) under its own linux user name (problematic linux access rights) OR
b) under its own linux network namespace (strongly preferred)

then redirect to pre-configured Tor TransPorts or DnsPorts.

(Similar to how we currently pre-configure multiple Tor SocksPorts currently.)

1 Like

Looks like the following does almost that. Untested. Looks interesting.

1 Like

orjail doesn’t have stream isolation support yet but that should be doable to add.


1 Like

Bonus: it integrates with firejail too :slight_smile:

1 Like





1 Like
1 Like