What should Tor Browser Updater (Whonix) do in a TemplateVM?

Qubes-Whonix
1

prerequisite knowledge:

Should tb-updater refuse to work in TemplateVM for better security?

In a TemplateVM, should tb-updater explain all this?

In a TemplateVM, should tb-updater store Tor Browser in ~/.tb as is?

In a TemplateVM, should tb-updater store Tor Browser somewhere in /var/… so it propagates to TemplateBasedVMs? Users would still have to manually make use of this. Copy frolm /var/… to /home.

2

[quote=“Patrick, post:1, topic:1193”]prerequisite knowledge:

Should tb-updater refuse to work in TemplateVM for better security?[/quote]

Yes, I think so.

That would be ideal.

No, not in my opinion. That would just lead to confusion or mistakenly thinking that TB has been updated (in the appVM) when it hasn’t.

I think having it detect/explain/close in a templateVM would be best. Otherwise, it could be set up this ^ way, with a script in /rw/config run by /rw/config/rc.local on startup to automatically copy TB from /var/… to /home/.tb each time. That would at least automate the process.

3

[quote=“revenant, post:2, topic:1193”][quote author=Patrick link=topic=1381.msg8813#msg8813 date=1435942753]
prerequisite knowledge:

Should tb-updater refuse to work in TemplateVM for better security?[/quote]

Yes, I think so.

That would be ideal.[/quote]
Okay.

No, not in my opinion. That would just lead to confusion or mistakenly thinking that TB has been updated (in the appVM) when it hasn’t.[/quote]
Right. Of course. Better to not cause confusion.

[quote=“revenant, post:2, topic:1193”][quote author=Patrick link=topic=1381.msg8813#msg8813 date=1435942753]In a TemplateVM, should tb-updater store Tor Browser somewhere in /var/… so it propagates to TemplateBasedVMs? Users would still have to manually make use of this. Copy frolm /var/… to /home.
[/quote]

I think having it detect/explain/close in a templateVM would be best.[/quote]
That’s the easiest and simplest way.

Otherwise, it could be set up this ^ way, with a script in /rw/config run by /rw/config/rc.local on startup to automatically copy TB from /var/... to /home/.tb each time. That would at least automate the process.
But may also overwrite something unwanted.

I think let’s go with the simpler way. Not such a big deal anyhow, because we’ll pre-install Tor Browser in Qubes-Whonix 11. And Tor Browser comes with its own updater. So there should be little need for tb-updater. No need to go crazy about it.

4

I hate to heat this up again after we would a nice and simple solution… But something has not been considered yet. Disposable VMs. We don’t have instructions for those yet (TODO, help welcome!), and I don’t know yet if that would even work yet without further development. But let’s suppose Whonix-Workstation could be started as Disposable VM.

In that case, it would be very desirable if the TemplateVM could come with an up to date version of Tor Browser so it can be used quickly.

5

[quote=“Patrick, post:1, topic:1193”]prerequisite knowledge:

Should tb-updater refuse to work in TemplateVM for better security?[/quote]

No. I disagree with the notion that this would be any more secure than updating within each VM individually. The TemplateVM is ultimately responsible for the security of each VM that shares it’s rootfs (and inherits its /home). As it is already the epicenter of trust, installing Tor Browser to it’s /home in no way increases our risk. If somehow the updating process of Tor Browser can infect/fool/etc. the TemplateVM, it can do the same to all VMs individually. We can’t treat TB as sacred when we can be just as fucked by a malicious curl package.

If anything, this will increase security because the user will only have to focus on one install. As you state “the intelligence of the user is utilized as a sanity check,” (in regards to DoS, rollbacks, and indefinite freeze attacks) and when I have to do the same monotonous task 10 times over I’m less likely to take as much care in the process.

But, if you disagree with me, why not have it both ways? Allow the user to choose whether to install it to the TemplateVM rootfs or not.

In a TemplateVM, should tb-updater explain all this?

Yes, whatever all this ends up being.

In a TemplateVM, should tb-updater store Tor Browser in ~/.tb as is?

Sounds like a fine choice to me. Don’t see why this really matters. Just document it or have the GUI dialog inform the user.

In a TemplateVM, should tb-updater store Tor Browser somewhere in /var/... so it propagates to TemplateBasedVMs? Users would still have to manually make use of this. Copy from /var/... to /home.

/var/ is for files written to during system operation (e.g., cache, log, and lock files). /opt/ would be a more canonical (not the company, it’s a word too–just putting that out there because you’re German, even though your English is great) choice.

revenant’s suggestion to load TB into ~/.tb/ is not a bad idea, but the command should use an if statement that only moves your old TB aside (maybe to ~/.tb-old/) if the one in root is a newer version. I export my bookmarks to HTML and then import them in the new TB after upgrade and I don’t want to do this after every VM restart. Further, I have my security slider set to different levels in different VMs and would not like to have to remember to reset it each time I restart a VM.

Actually, what would be best for myself is to set the security slider to high in the TemplateVM after each upgrade, that way I don’t accidentally use Javascript in a high-security VM after upgrade. I’m not suggesting you automate this process though.

On the other hand, what would be nice to automate, if at all possible, is the export of bookmarks from the old browser and into the new browser. This could involve a single user-set switch in the rc.local script, on a per-VM basis, that is off by default. I only keep bookmarks in some of my Workstation VMs, so this would be best. This last suggestion of course is just an extra nicety I don’t expect you to write, and I might try my hand at myself, once the script called by rc.local has been figured out.

6

Yes, I am also convinced now, that tb-updater needs to be capable to run in a TemplateVM one way or another. Specifically with multiple Whonix based AppVM and at some point DispVM this really is required.

More answers to come.

7
more canonical (not the company, it's a word too--just putting that out there because you're German, even though your English is great)
Hehe. Yes, it's awful how companies such as canonical take over terms such as "canonical" and "Ubuntu" or how facebook redefined the term "friend".
revenant's suggestion to load TB into ~/.tb/ is not a bad idea, but the command should use an if statement that only moves your old TB aside (maybe to ~/.tb-old/) if the one in root is a newer version.
Backups are already created. Similar to this. Nothing gets lost without backup. Code: https://github.com/Whonix/tb-updater/blob/470c9ed8a1e14fdcf411d7b1f6a8d2c19f13833a/usr/bin/update-torbrowser#L1349-L1352
I export my bookmarks to HTML and then import them in the new TB after upgrade and I don't want to do this after every VM restart. Further, I have my security slider set to different levels in different VMs and would not like to have to remember to reset it each time I restart a VM.

Actually, what would be best for myself is to set the security slider to high in the TemplateVM after each upgrade, that way I don’t accidentally use Javascript in a high-security VM after upgrade. I’m not suggesting you automate this process though.


Yes. Automated interaction with TBB is should avoided. That’s too fragile, because TPO keeps changing stuff, so this would break. At least offically avoided. For personal use you can always extend tb-updater or whatnot with scripts.

On the other hand, what would be nice to automate, if at all possible, is the export of bookmarks from the old browser and into the new browser. This could involve a single user-set switch in the rc.local script, on a per-VM basis, that is off by default. I only keep bookmarks in some of my Workstation VMs, so this would be best. This last suggestion of course is just an extra nicety I don't expect you to write, and I might try my hand at myself, once the script called by rc.local has been figured out.
tb-updater already has a tb_patch_... mechanism. We could allow to plug in some code there. Or script this somehow otherwise.
8

As usual and as perhaps expected, any modifications to TBB you make in the TemplateVM before creating an AppVM are inherited by the AppVM. So you could set the security slider to high there.

However, I am not sure if that could have any negative side effects. Such as if on first start of TBB any random seeds are created then, which would then be shared by various AppVMs while they should not. So the sanest thing to do could be to do only file based modifications, but to not ship TBB.

9

New chapter in the development wiki… Contains all the prerequisite knowledge that came to my mind. And brainstorming.

After reading, please feel free to restart your argument. And/or to add it to the brainstorming section.

10

I’m still trying to figure out how to get whonix to run under qubes (he he) but my naive expectation is that Whonix would serve as a TemplateVM. In other words, it seems to me bad security to have whonix or any of its applications run in the default fedora template VM or even in the optional debian wheezy template vm. The reason is obvious…the whole point of qubes is security by isolation (compartmentalization) so it seems a violation of that principle to mix whonix with qubes at the template level. A compromise in tor software should not run the risk of infecting my entire default template vm…no no no. When the user looks at the Qubes Vm Manager screen under the template column they should see “WhonixTemplate”. Then the user creates disposable VM based upon that whonix template. This way the whonix disposable VMs gets the benefit of non-persistence.

This may mean as a practical matter that there needs to be a separate sys-net and firewall vm based off the whonix template vm. This seems the right answer in terms of stream isolation too. I don’t have any conception of the coding burden this imposes but it seems at the abstract level the best approach.

edit:

"Unfortunately, this means, if a user had for example 5 different Qubes-Whonix-Workstation based AppVMs where Tor Browser is in use, the user would have to update each of its 5 TBBs.

Maybe a non-issue? TBB 5's and above internal updater (already released as stable by TPO) have automatic updates enabled by default."

They shouldn’t have to update TBB five times. What they should do is simply delete those disposable app vms and then create five new disposable app vms based off the newly updated Whonix template VM.

11

Fedora, Debian, Whonix, and others, are all separate templates.

12

That makes perfect logical sense. So then why is there an issue at all? See my edit in the post above which responds directly to the question you pose here:

The user shouldn’t be “restarting” the old app vm and expecting it to update. They should be deleting it and creating a new app vm off the new template.

13

Not everyone wants to use it always the disposable way.

Usually, for all normally packages software from apt [or yum] repositories, users update their TemplateVM. Once they restart their TemplateBasedVMs, those will also be updated. Now, with TBB, that’s more difficult, because it’s not available as deb package.

14

That’s true but that doesn’t mean that the best answer lies with Whonix. For example, if the data that needs to carry over between TBB updates is bookmarks FF has an import/export function that much quicker than updating TBB five times. There are also third-party add-ons to FF that also can back up other settings. So what is the demand that such functions be handled in the background by Whonix?

Are you troubled by the appearance that Whonix is out of touch with the way the rest of Qubes works or the reality? To my mind, I do not see the issue. Whonix!=Qubes. It would be one thing if Whonix where to be shipped as a default template with Qubes–then issues such as uniform functionality might carry more weight. But as it stands today the fact that updates with Whonix do not work precisely the same way as the rest of Qubes is no big deal–just another feature to document.

Anyway, that is my 02 cents. FWIW.

15

The long term plan is to install Qubes-Whonix by default and to make it easier to use by mortals.

16

FYI

[hr]

Tor Browser Updater (Whonix) latest development status:
https://phabricator.whonix.org/T400

[hr]

whonixcheck Tor Browser update check:

Tor Browser update check has been deprecated, because local version detection code was broken since Tor Browser got its own internal updater. Also since Tor Browser now automatically updates itself without asking, there is less need for this test.
https://phabricator.whonix.org/T400
17

A Qubes specific notice has been added to Tor Browser Downloader (Whonix)'s update confirmation screen:

Qubes specific notice: Currently running inside a TemplateVM.
Due to technical limitations, running this program in this TemplateVM will not update Tor Browser in TemplateBasedVMs, which are based on this TemplateVM. Only newly created TemplateBasedVMs, which are based on this TemplateVM will benefit from this. To update Tor Browser inside existing TemplateBasedVMs, please update Tor Browser inside TemplateBasedVMs.

18

The full message will read…

Download confirmation

Curently installed version: Installed. (Folder /home/user/.tb/tor-browser_en-US exists.) Locally installed Tor Browser version detection not implemented.

Online versions:
[ ] …
[ ] …

Since The Tor Project configured TBB to automatically update itself, if you would like to keep your browser profile and update rather than re-downloading TBB, you are better off using Tor Browser’s internal updater. In that case, say no now.

This program (Tor Browser Downloader (Whonix)) is incapable of keeping user data.
YOUR BROWSER WILL BE KILLED.
YOUR WHOLE BROWSER PROFILE INCLUDING BOOKMARKS AND PASSWORDS WILL GET REPLACED.

A backup of your old Tor Browser and settings will be created in folder /home/user/.tb.
It is a good idea to delete old TBB backups once in a while if you are running low with disk space.

Only versions still considered secure should be listed here. Higher version numbers does not necessarily mean more secure here. Could be alpha or beta versions. In most cases you are best off choosing the lowest version number among them.

Learn more about this Download Confirmation Screen.

Qubes specific notice: Currently running inside a TemplateVM. Due to technical limitations, running this program in this TemplateVM will not update Tor Browser in TemplateBasedVMs, which are based on this TemplateVM. Only newly created TemplateBasedVMs, which are based on this TemplateVM will benefit from this. To update Tor Browser inside existing TemplateBasedVMs, please update Tor Browser inside TemplateBasedVMs.

Download now?

Yes | No

Any comments?

Kinda messy. I know. But without The Tor Project solving the original issues (= non-existing Debian Package of Tor Browser - Get TorBrowser in Debian (#3994) · Issues · Legacy / Trac · GitLab - Make a deb of the Torbrowser and add to repository (#5236) · Issues · Legacy / Trac · GitLab), little can be done about this.

Suggestions for improved wording are appreciated.

20

Will stop in Whonix 12.

22

I would re-define the ‘updater’ role as strictly a downloader. If it notices a TBB is already present, warn the user that the browser + browser data will be overwritten if they proceed. Short and to the point.

If there is a way to automatically launch TB in the check/update mode then that could be an option as well.