[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Idea for aqrexec service to install new versions of Tor browser to a list of VMs

Installing and updating Tor browser on VM by VM basis is very cumbersome (time and bandwidth-wise) when you have 10 or so separate VMs you’d like it in. It would be nice if you could update it in the template, and that could execute a qrexec service (really a script that is triggered and runs the qrexec service multiple times depending on the input parameters you give it) that would do the following:

  1. Prompt you with a gui asking which whonix-ws based VMs you’d like to update Tor browser in. Each one could have a checkbox and it could remember your last choice(s).

  2. If the first VM in the list of those chosen is already on, intiate a qrexec request. If it is rejected by the qrexec daemon, do not go any further and shutdown the process with an error report. The user probably made a mistake or otherwise your dom0 is really someone else’s.

  3. Supposing the user accepts it, whonix-ws template will send the verified Tor browser tar archive to the VM. The VM will then move the old one aside and extract the new one in it’s place. If everything goes right, it sends back an exit code 0. If something went wrong (this seems really unlikely considering how basic the operation is), we send back an error code and continue.

  4. Repeat steps 2-3 for the rest of the VMs selected in step 1.

The obvious threat here is for a malicious VM to somehow infect the template. It should not be too hard to express in Python that if the input coming back is not 0 or one of the recognized error codes, that an exception should be thrown and error printed that says “Hey, maybe VM X it totally pwn3d. You might want to check that out.”

Thoughts?

I could try writing this.

Actually… it seems like it might just be easier to install Tor browser to root. I understand why there is no point in doing so on a non-template-based Whonix setup, but as far as Qubes goes, this would provide a reliable way to upgrade and update Tor browser for all whonix-ws based VMs.

I don’t see any danger or difficulty to doing so, do you? You could simply modify your GUI tool to download and verify in /home, and then prompt root and install to / in whonix-ws template only.

Thanks for the suggestion. I’ll read this more carefully later.

In meanwhile, please check out the related discussion:
What should Tor Browser Updater (Whonix) do in a TemplateVM?
https://www.whonix.org/forum/index.php/topic,1381.0.html

After having read, please consider to restart/upgrade your argument if applicable.

Unrelated, but since you’re interested in Qubes-Whonix, perhaps also check out:
What should whonixcheck do when it detects being run inside a TemplateVM?
https://www.whonix.org/forum/index.php/topic,1380.0.html

Installing and updating Tor browser on VM by VM basis is very cumbersome (time and bandwidth-wise) when you have 10 or so separate VMs you'd like it in.
I agree.
It would be nice if you could update it in the template, and that could execute a qrexec service (really a script that is triggered and runs the qrexec service multiple times depending on the input parameters you give it) that would do the following:
1. Prompt you with a gui asking which whonix-ws based VMs you'd like to update Tor browser in. Each one could have a checkbox and it could remember your last choice(s).
Good.

But did you know already, that tb-updater is unable to keep your user settings? It renames your old folder so nothing is lost. Then installs a fresh one. Something important to know. I don’t think this limitation can be lifted in tb-updater. Upgrading Tor Browser is hard. (Upstream often changed the folder layout in past.) That’s what Tor Browser’s internal updater is for.

References:

So most likely your solution should rely on Tor Browser’s internal updater rather than tb-updater?

2. If the first VM in the list of those chosen is already on, intiate a qrexec request. If it is rejected by the qrexec daemon, do not go any further and shutdown the process with an error report. The user probably made a mistake or otherwise your dom0 is really someone else's.
Ok.
3. Supposing the user accepts it, whonix-ws template will send the verified Tor browser tar archive to the VM. The VM will then move the old one aside and extract the new one in it's place. If everything goes right, it sends back an exit code 0. If something went wrong (this seems really unlikely considering how basic the operation is), we send back an error code and continue.
Ok. (But my above considerations apply.)
4. Repeat steps 2-3 for the rest of the VMs selected in step 1.
Ok.
The obvious threat here is for a malicious VM to somehow infect the template. It should not be too hard to express in Python that if the input coming back is not 0 or one of the recognized error codes, that an exception should be thrown and error printed that says "Hey, maybe VM X it totally pwn3d. You might want to check that out."
Ok.
Thoughts?
Sounds good overall.
I could try writing this.
Yes.

I am not sure into which package this belongs. Perhaps https://github.com/Whonix/tb-updater. Or https://github.com/Whonix/qubes-whonix.

Actually... it seems like it might just be easier to install Tor browser to root.
I don't see any danger or difficulty to doing so, do you? You could simply modify your GUI tool to download and verify in /home, and then prompt root and install to / in whonix-ws template only.
Tor Browser refuses to run as root. (Could be patched, but probably not a good solution, would cause other confusing permission issues.)

Due to Tor Browser binaries being entangled with user data in the same folder (Tor Browser is packaged and only available as portable app) (“upstream issue”?), you cannot install Tor Browser to /usr/bin or /opt or so as root and then run it as a user having your profile in user’s home folder.

I understand why there is no point in doing so on a non-template-based Whonix setup, but as far as Qubes goes, this would provide a reliable way to upgrade and update Tor browser for all whonix-ws based VMs.
We can consider any Qubes specific command line switches [run as root, install to root etc.] switches for tb-updater, but as said above, I don't think it would work that way.

Just a note that /usr/local/ actually belongs to the private.img of your AppVM. It’s symlinked to /rw/usrlocal/ . Therefore, it would not be wise to install TB there.

/usr/bin/ on the other hand, you should not install to because /usr/bin/X11/ hangs out there and that’s a weird folder. Try going to /usr/bin/X11/ and then /usr/bin/X11/X11, seconds later you’ll be 10 X11 dirs deep wondering where the fuck you are. It’s almost as if it’s symlinked to itself… no… that’s not possible!1!1! Sorry, it’s late, I say go with /opt/.

No one has demonstrated yet, that it’s possible to install & run [ & update ] TBB to either /usr/, /opt/ or anything of that sort. By upstream default, you are supposed to have it in your home folder.

Brainstorming: We could download and extract TBB to /opt/* [running tb-updater as root or something, but nevermind] and then have somehow have AppVM copy it from there to user’s home folder.

Unless this proposal is refined, we will be going with https://phabricator.whonix.org/T417 only.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]