ID: 797PHID: PHID-TASK-ixkd72wdhcemccfa5nhbAuthor: yzxdStatus at Migration Time: resolvedPriority at Migration Time: Normal
The uwtwrapper script does not handle symlinks properly.
For example, git installs two symlinks at /usr/bin/git-receive-pack and /usr/bin/git-upload-archive that point to /usr/bin/git. I’m not well versed in bash, but I think that $uwtwrapper_parent is incorrectly set to the symlink, rather than what the symlink points to. The script then tries to run /usr/bin/git-receive-pack.anondist-orig, rather than /usr/bin/git.anondist-orig. This causes the following error.
uwtwrapper uwt wrapper ERROR: /usr/bin/git-receive-pack.anondist-orig does not exist.
2018-05-28 04:24:07 UTC
I’ve created a pull request that fixes this issue here . It is a bit clunky since I’m not well-versed in bash, so any criticism is welcome.
Edit: This fixes the symlink part of the issue, but git appears to change behavior based on what symlink it was called by. I haven’t a clue on how that would be fixed.
2018-05-28 05:05:34 UTC
! In T797#16103, @yzxd wrote:here .
That looks really good!
Edit: This fixes the symlink part of the issue, but git appears to change behavior based on what symlink it was called by. I haven’t a clue on how that would be fixed.
Dunno either how to fix. How does git figure out by which symlink it was called?
Does it help to add uwt wrappers for /usr/bin/git-receive-pack and /usr/bin/git-upload-archive? I guess either way we should add uwt wrappers for those?
2018-05-28 13:55:44 UTC
How does git figure out by which symlink it was called?
I thought they were using some magic, but the program name is passed to it as the first argument and parsed [[ git/git.c at e144d126d74f5d2702870ca9423743102eec6fcd · git/git · GitHub | here]]. So it takes git-receive-pack and makes it the same as git receive-pack.
After looking into it a bit further, there is definitely a way to fix it. You can emulate git-receive-pack by just calling exec -a git-receive-pack git without uwt. The -a argument passes its value as the first argument to the program.
Does it help to add uwt wrappers for /usr/bin/git-receive-pack and /usr/bin/git-upload-archive? I guess either way we should add uwt wrappers for those?
Adding wrappers for them does seem to fix the symbolic link issue without changing any of the code, but git still only gets /usr/bin/git.anondist-orig as its first argument. It might make sense to do so.
2018-05-29 01:53:41 UTC
2018-06-02 21:37:38 UTC
I think I may have another solution that involves just adding the wrapper. If the wrappers were added for them and the symlink renamed to /usr/bin/git-receive-pack.anondist-orig, perhaps the symlink could be changed to point from /usr/bin/git to /usr/bin/git.anondist-orig. Would that still provide stream isolation?
As for fixing it in the code, I’ve done limited research so far. The exec "$uwtwrapper_parent.anondist-orig" "$@" cases at the end of the script could be fixed easily with the -a parameter. As for faketime, it appears that it does preserve the first argument (e.g., faketime 'yesterday' random-executable would pass it as random-executable, rather than faketime). I haven’t tested time_privacy or torsocks yet.
2018-06-05 15:11:44 UTC
2018-06-05 15:30:28 UTC
user@host:~$ ls -la /usr/bin/git-receive-pack
lrwxrwxrwx 1 root root xxx 7 /usr/bin/git-receive-pack -> git
With your patch https://github.com/Whonix/uwt/pull/5 which is now merged…
export uwtwrapper_verbose=1
git-receive-pack clone https://github.com/Whonix/uwt.git
First execution of uwt.
exec git clone https://github.com/Whonix/uwt.git
Second execution of uwt.
exec torsocks /usr/bin/git.anondist-orig clone https://github.com/Whonix/uwt.git
Looks really good, right? Solved already?
2018-06-05 16:54:18 UTC
/usr/bin/git-receive-pack symlinks to git.
/usr/bin/git symlinks to the bash based uwt wrapper git.anondist.
Interestingly during execution of /usr/bin/git, ${BASH_SOURCE[0]} will be set to /usr/bin/git-receive-pack.
This is what will happen during execution of /usr/bin/git.
export uwtwrapper_parent=/usr/bin/git-receive-pack
exec /usr/lib/uwtwrapper
What the user has run is git-receive-pack, which symlinked to git but what is actually running is /usr/lib/uwtwapper (while uwtwrapper_parent is being set to /usr/bin/git-receive-pack). So uwt falsely “thinks”, that uwtwrapper_parent is /usr/bin/git-receive-pack, while actually git is the latest script that has executed /usr/lib/uwtwapper.
Related:
2018-06-06 21:47:11 UTC
Looks really good, right? Solved already?
Yup, it’s working great! I just tested git pushing to a server with uwt installed and the push went through successfully, so it appears git now gets the proper executable name (git-receive-pack). I think this should be safe to close now.
Edit: I didn’t realize I had git-receive-pack symlinked to git.anondist-orig. The symlink issue is fixed, but it still only gets git as the first argument, rather than git-receive-pack. This causes git pushes to still fail, since git interprets git-receive-pack differently than just git. It should output something like You must specify a directory. with some other usage tips rather than the git help page.
2018-06-13 06:53:01 UTC
2018-06-13 06:54:41 UTC
2018-06-15 02:19:06 UTC
If yes… We could uwtwrapper_parent into variable uwtwrapper_parent_previous and pass it to exec -a on nested execution of uwt (when uwtwrapper_counter is bigger than 1).
For the simple exec "$uwtwrapper_parent.anondist-orig" "$@"s at the end of the script, I believe the -a parameter will work fine.
I tried testing exec -a git-receive-pack faketime "today" git as well as exec -a git-receive-pack torsocks git, but it doesn’t appear that they pass the zeroth argument to the program and there’s no similar -a parameter for them. The only solutions to these I can think of are another wrapper or filing a feature request with those projects.
The time_privacy script could probably be amended to allow a similar functionality to -a, since it’s local to uwt (if it doesn’t already, I haven’t checked).
2018-06-15 10:21:05 UTC
2018-06-17 23:53:08 UTC
I’ve created pull request #6 that fixes this issue and doesn’t break any functionality. It adds a new wrapper (/usr/lib/uwtexec), which uses a new variable $uwtwrapper_zeroarg, $uwtwrapper_parent, and the original parameters ($@) to execute the program.
I haven’t verified that torsocks still isolates the stream (I don’t know enough to do so), but I believe it should still work normally.
2018-06-18 00:33:48 UTC
2018-06-18 18:46:58 UTC
For exec calls without any wrappers (faketime or torsocks), the -a parameter will work fine.
For exec calls with wrappers, exec -a {zeroarg} torsocks program.anondist-orig will provide {zeroarg} as the zeroth argument to torsocks, but torsocks will not pass it onto program.anondist-orig. We could submit feature requests to the projects and ask for a parameter similar to exec’s -a, but I’m not sure how long that would take for them.
2018-06-19 01:58:57 UTC
2018-06-20 01:57:48 UTC
2018-06-21 01:02:47 UTC
2018-06-22 01:26:50 UTC
See https://github.com/Whonix/uwt/pull/6/files#r196984725 .
That specifically won’t work due to the wrappers not passing on the zeroth argument, but my above comment with the exec within an exec will work .
Do you think introducing a second wrapper cannot be avoided?
It can definitely be avoided, I just didn’t realize it at the time. I’ll close #6 and make another that doesn’t require the additional wrapper.
I thought it could be avoided by using exec within an exec, but it turns out exec is a shell builtin and needs to be in a shell script. You can test this by running exec exec, which will return something like this: -bash: exec: exec: not found.
2018-06-22 04:05:07 UTC
2018-06-23 16:12:04 UTC
The two main issues of this issue, following symlinks and passing the zeroth argument properly, do work correctly now with the update in the testers repository.
torsocks stream isolation
I’ve tested that torsocks still isolates streams by changing its TorAddress in /etc/tor/torsocks.conf to 127.0.0.1, which didn’t have a Tor daemon listening on it. For some strange reason, the change didn’t apply immediately, but after a few minutes all binaries with wrappers failed to connect to the outside world.
bindp
On the first run, it failed instantly (for me), since I’m running Debian Stretch. The /sbin/ifconfig command no longer exists and the ip command is now recommended. This can be solved by installing the net-tools package, which provides /sbin/ifconfig.
On the second run with /sbin/ifconfig present, it fails with eth0: error fetching interface information: Device not found. This is due to Debian 9 using systemd 197+, which implements Predictable Network Interface Names . I’m not certain how we could fix the default, but I simply specified my interface’s name by prefacing the command with bindp_interface=ens3.
On the third run, I got the error ERROR: ld.so: object '/usr/lib/libindp.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored., which means the bindp package was not installed.
On the fourth run with bindp installed, it succeeded without any error. I ran both bindp_dispatch=true BIND_ADDR="127.0.0.1" wget http://whonix.org and wget http://whonix.org. The first command failed (as it should, since it only allows local connections, see the second example on this ) while the second command succeeded.
2018-06-25 04:04:39 UTC
Could you try please any application depending on #bindp is still functional? I guess onionshare would be the easiest.
OnionShare - Whonix
Are you using #uwt outside of Whonix? That’s interesting! Didn’t know that happens.
In Whonix we are disabling systemd predictable network interfaces.
I will fix the missing dependencies of #uwt by adding #bindp and net-tools to Depends:.
which didn’t have a Tor daemon listening on it
btw that is related to anon-ws-disable-stacked-tor
2018-06-26 01:26:30 UTC
Could you try please any application depending on bindp is still functional? I guess onionshare would be the easiest.
I’ve tried getting Onionshare v1.3.1 to work, but I’m stuck on step 7 on the wiki page you linked me. It mentions something about onion-grater, but that doesn’t exist on my Gateway installation (13.0.0.1.4 for libvirt). I tried skipping the step, but it appears that it won’t recognize the /var/run/tor/control and tries to fallback to Tor’s control port at 127.0.0.1:9050.
I tried to circumvent this by just setting the control port to 10.152.152.10:9052 and the proxy to 10.152.152.10:9050, but it failed with the message Connected to 10.152.152.10:9052, but can't authenticate. Maybe this isn't a Tor controller?.
I then verified that the control port actually worked, by running telnet 10.152.152.10:9052 and got a 250 OK to the authenticate command.
I’m not really sure where to continue from here, I can’t even get it to run on its own.
2018-06-26 02:56:32 UTC
2018-06-28 17:21:48 UTC
It needs to be developed and tested on Whonix 14.
I must have missed the banner at the top of the page, whoops!
I just tested OnionShare on a fresh Whonix 14 installation using the latest #uwt in the testing repository and it went a lot smoother than trying it with 13. After installing, I tried sharing a few files and it worked perfectly.
I also tested the version in the Debian testing repository and it seems they’ve updated it to version 1.3, but the current is 1.3.1.
2018-06-29 03:54:27 UTC