Managing programs without Tor DNS Support / orjail

Jason suggested to modify
Whonix ™ Default Application Policy in order to
not be adamant about properly working socks support for stream isolation.

Like not installing electrum by default because of this (
⚓ T215 install electrum bitcoin thin client by default? ) we let the perfect be the ennemy
of the good and let users stand in the rain.


Meanwhile I have a suggestion on how Gajim’s traffic can be forced to use stream isolation. What if it is installed under its own user account and then you can use bindp to force all traffic for that user over its own isolated stream? Does that make sense? Can it fix things?

bindp use case: ricochet or onionshare open a server port on to be accessible from the hidden service incoming connection. This won’t work in Whonix since the hidden service incoming connection is coming from Whonix-Gateway which is a non-localhost connection. bindp is used to force that application to listen on another interface so it can accept the connection. So bindp has nothing to do with it here since gajim doesn’t open server ports / needs no unsolicited incoming connections.

Once we’re using iptables redirection, no torsocks or anything is required. Perhaps we could have this a generic solution. Applications running under their own linux operating system user name, and then redirected… Wait… Redirect how and where? Could only be redirected to Tor’s DnsPort / Tor’s TransPort, so wouldn’t solve any stream isolation issue. I wouldn’t know any translation from operating system networking default traffic (and iptables) to socks that’s why iptables can help with leak prevention but then connectivity just breaks since iptables is not a socksifier. Would be cool to have some iptables to socks tool. Dunno if that exists.

Indeed it might be the wisest thing to do if no other choice exists. At least it will make it easier for users to have safely configured apps, especially if they are intent on manually installing them anyway.

I did some digging. Its possible with redsocks to redirect DNS over TCP. Here is a detailed outline of the options you have with redsocks:

OP has combined it with iptables though in his case, the software he’s using isn’t working but its a useful example of how it hcan be done:

Another tool that des something similar is GitHub - jtripper/dns-tcp-socks-proxy: Simple daemon to tunnel DNS requests over SOCKS

1 Like

Other useful tools in case the previous were duds:

ttdnsd accepts DNS requests via UDP and forwards the to a resolving nameserver via TCP. The actual requests are really just forwarded so one has complete access to the nameserver ttdnsd is talking to.

ttdnsd only connects to the resolving nameserver after receiving a request via UDP. For each connection ttdnsd randomly selects one of the nameservers it knows about (see OPTIONS below). The connection will be used for forwarding multiple requests in a pipelined fashion and is kept open only until no more requests are received via UDP. This pipelining is required to overcome the initial connection overhead time which is quite long when using TOR.

Simple Linux epoll-based single thread SOCKS5 client. Supports getting destination address with SO_ORIGINAL_DST (for use with -j REDIRECT iptables target) and telling that address to SOCKS server.

Alternative, more complete libevent-based implementation: redsocks

No licensing info found

python script setting up a transparent proxy to forward all TCP and DNS traffic through a SOCKS / SOCKS5 or HTTP(CONNECT) proxy using iptables -j REDIRECT target

Free license

1 Like

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