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 ( https://phabricator.whonix.org/T215 ) we let the perfect be the ennemy
of the good and let users stand in the rain.
HulaHoop:
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 127.0.0.1 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:
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
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.
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.
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.
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.
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.
