Managing programs without Tor Socks / DNS Support

phabricator-migrator · February 19, 2024, 5:42pm

Information

ID: 772
PHID: PHID-TASK-ycdezhyl5wpjqa3mj6lq
Author: HulaHoop
Status at Migration Time: open
Priority at Migration Time: Normal

Description

Hoevenstein’s AORTA tool can be used to force applications that don’t honor Tor DNS which breaks stream isolation.

Comments

Patrick

2018-02-28 17:10:56 UTC

Does aorta support stream isolation? Doesn’t look like? It uses hardcoded TransPort / DnsPort.

aorta source code:
#define TOR_TCP_PORT              "9040"
#define TOR_DNS_PORT              "9041"
Without stream isolation it’s as good as not using aorta.

Please request a feature to do configure this by command line or environment variable.

Does it modify Whonix-Workstation firewall rules or is this contained through cgroup usage? Please test as per Dev/Firewall Refactoring - Kicksecure.

Another issue: compiled code and not available in packages.debian.org. We could use a similar solution to bindp.

Does it even work with electrum?

Is it better (less likely to leak) than torsocks electrum (if torsocks would work, we’d already have an uwt wrapper?)?

AORTA a transparent Tor proxy for Linux programs

What can go wrong?

AORTA can only do its magic if the program it starts is under its control. In technical terms: the program must be a child process of the aorta program.

Some programs escape aorta’s control if the program is already running. These programs detect at start if there is a running instance of the program. If so, they do not start a new program but instead clone the running program. This clone is a child of th

Can you ask the author please if he considered running under different linux user account name (temporarily and dynamically created) or linux network namespaces? Perhaps that would be more leak proof?

Rewrite in scripting language since C is not really required?

Patrick

2018-06-23 06:41:50 UTC