Uwt temporary files issue

Patrick · November 15, 2015, 7:47pm

Seems like a bug in uwt. One that was never noticed by anyone. Perhaps because in Whonix, uwt first runs as user while in qubes-whonix it first runs as root. Setting ownership to user:user is a limited workaround. Would fail as soon as other user accounts start using uwt. Needs a fix in uwt.

Related to these ~20 lines of code:

github.com

Whonix/uwt/blob/c93bffdc64042ff885556eefd19d5c6b27044ff8/usr/bin/uwt#L183-201


fi


true "UWT: We are armed with the following torsocks: $TORSOCKS"


dpkg_query_exit_code="0"
torsocks_installed_version="$(dpkg-query --show --showformat='${Version}' "torsocks")" || { dpkg_query_exit_code="$?" ; true; };


dpkg_compare_versions_equals_exit_code="0"
dpkg --compare-versions "$torsocks_installed_version" ge "2" || { dpkg_compare_versions_equals_exit_code="$?" ; true; };


if [ ! -d "/tmp/uwt" ]; then
mkdir --parents --mode=g+rw "/tmp/uwt"
fi


## Define our torsocks config file.
TORSOCKS_CONF_FILE="$(mktemp --tmpdir="/tmp/uwt")"
if [ ! "$?" = "0" ]; then
echo "mktemp failed with exit code $?!"
exit 1
fi
export TORSOCKS_CONF_FILE

The following code is non-ideal.

if [ ! -d "/tmp/uwt" ]; then
   mkdir --parents --mode=g+rw "/tmp/uwt"
fi

[hr]

Background:
What’s uwt good for anyhow?

torsocks has no options for passing ip/port by command line [for stream isolation]. Neither an option to pass a config file by command line. The only option to set a configuration file is setting the TORSOCKS_CONF_FILE environment variable. (upstream feature request)

uwt dynamically generates a torsocks config file and sets that environment variable. The problem with that approach was a massive amount of tmp.xxx files piling up /tmp where users wondered about. Therefore a sub folder /tmp/uwt was created to aggregate all those config files there. Why wasn’t the config file deleted? Because ‘torsocks’ was called by using ‘exec’ and there is no way to cleanup after.

[hr]

I attempted a fix. Abolished use of exec. No longer using a sub folder. Temporary torsocks configuration files are now cleaned up by an EXIT trap.

[hr]

Long story short:
Should be fixed in uwt >= 1.7-1.

Hopefully not more issues were introduced than fixed. Needs testing.

In Whonix 11.0.0.2.2-developers-only (not yet tested) from

the following can be deleted.

Patrick · November 15, 2015, 7:47pm

That won’t be it.

I remember why ‘exec’ was being used in the first place. Without ‘exec’ progressing unix signals (sigterm etc.) does not work. Not sure if there is a solution to that.

And when using ‘exec’ there is no way to cleanup afterwards.

Patrick · November 15, 2015, 7:47pm

Worked on signal handling in uwt >= 1.8-1. But that doesn’t work either.

Test cases.

(Over ssh! Because git is torified by uwt which uses ssh which is torified as well.)

Test case 1 is functional, while test case 2 is not.

Patrick · November 15, 2015, 7:47pm

Back to per-user temporary folders in uwt >= 1.9-1. Not the most pretty solution, but all test cases are functional.

nrgaway · November 15, 2015, 7:47pm

Is there anything better than UWT?

Why would it be so difficult to re-route packets; can’t iptable rules be set up or something similar? Hooking into the kernel or network device would allow some advanced routing? Use a dummy device?

Guess one day I should look into the inner workings of exactly what is required. It would be nice to not have so many uwt wrappers.

nrgaway · November 15, 2015, 7:47pm

[quote=“Patrick, post:1, topic:1113”]Long story short:
Should be fixed in uwt >= 1.7-1.

Hopefully not more issues were introduced than fixed. Needs testing.

In Whonix 11.0.0.2.2-developers-only (not yet tested) from

the following can be deleted.

FYI, I had removed Whonix from qubes-linux-template-builder a few months ago and placed it into its own package (qubes-template-whonix) https://github.com/nrgaway/qubes-template-whonix/tree/Whonix11

Patrick · November 15, 2015, 7:47pm

Is there anything better than UWT?

Not that I know. Last time I checked, Tails also had no better solution or even idea.

Ideally applications support socks proxy settings. Then it’s simple and socksification by uwtwrapper -> uwt -> torsocks is not required. But if they don’t, there is just torsocks. And uwtwrappers / uwt help setting them up by default.

Why would it be so difficult to re-route packets; can't iptable rules be set up or something similar? Hooking into the kernel or network device would allow some advanced routing? Use a dummy device?

Because for stream isolation, traffic has to be distinguished at application level. Those levels are too low. Let's say, at least no one published a great idea how it could be solved.

Guess one day I should look into the inner workings of exactly what is required. It would be nice to not have so many uwt wrappers.

Implementing https://trac.torproject.org/projects/tor/ticket/11726 (C code) would certainly help abolish the temporary config file creation hack.

nrgaway · November 15, 2015, 7:47pm

So from what I gather tor socks is already able to configure itself for port/ip via TORSOCKS_CONF_FILE environment variable only and not via CLI. torsocks is written in C code.

It is further suggested that providing a command line interface to torsocks would eliminate the need for UWT?

It seems like a real trivial task to implement a CLI for torsocks if it already has the inner-workings to reconfigure itself via ENV variable.

If my assumptions are correct, then why don’t we just modify torsocks to allow CLI and provide patch upstream?

Patrick · November 15, 2015, 7:47pm

So from what I gather tor socks is already able to configure itself for port/ip via TORSOCKS_CONF_FILE environment variable only and not via CLI. torsocks is written in C code.

Correct.

It is further suggested that providing a command line interface to torsocks would eliminate the need for UWT?

Would eliminate need for creation of a temporary configuration file.

It seems like a real trivial task to implement a CLI for torsocks if it already has the inner-workings to reconfigure itself via ENV variable.

For someone who speaks C, yes...

If my assumptions are correct, then why don't we just modify torsocks to allow CLI and provide patch upstream?

Do you speak C or know anyone contributing this in C?

nrgaway · November 15, 2015, 7:47pm

Correct.

Would eliminate need for creation of a temporary configuration file.[/quote]
but but the need for use of UWT?

[quote]It seems like a real trivial task to implement a CLI for torsocks if it already has the inner-workings to reconfigure itself via ENV variable.[/quote] For someone who speaks C, yes...

If my assumptions are correct, then why don’t we just modify torsocks to allow CLI and provide patch upstream?

Do you speak C or know anyone contributing this in C?

I do speak C, just not as well as python

Patrick · November 15, 2015, 7:47pm

but but the need for use of UWT?

Because when users type or scripts call for example [font=courier]apt-get [...][/font]*, what really needs to happen is [font=courier]torsocks -t -p apt-get [...][/font]. Why? So socksification with proper stream isolation is applied. For that, a wrapper is required. uwt is an implementation of such a collection of wrappers.

[size=8pt]* apt-get itself does not support proxy settings.**
** [font=courier]Acquire::proxy[/font] is a disproved*** myth.
*** Disproved because apt-get’s source code does not mention [font=courier]socks[/font] and because apt-get developers also confirmed, that there is no such feature.[/size]