How do I customise Tor Browser in a Whonix TemplateBased DVM in Qubes-Whonix

Qubes-Whonix
1

In Whonix 13, I maintained things like bookmarks, HTTPSEverywhere rules, Security settings in the whonix-ws-dvm (TemplateBased DVM), so that my Whonix DispVMs were preloaded with those settings. Very convenient for using many DispVMs a day (I don’t use the anon-whonix appVM that’s based on whonix-ws Template).

Now in Whonix 14 I can’t start the Tor Browser in the DVM template (get the message to not do so).

How are other people maintaining their settings so they don’t have to configure every DispVM? I must start about 50 DispVMs a day, this will get very laborious otherwise.

I guess I could try and add the configs directly to /rw/user/ somewhere within the Tor Browser profile? Is that the best (only) way now?

Also I note that I can’t start Tor Browser in the whonix-ws-14 TemplateVM. But the wiki says:

Do not run Tor Browser Downloader by Whonix inside the DVM Template (whonix-ws-14-dvm)! It should only be run in the TemplateVM (whonix-ws) or whonix-ws-based AppVM (anon-whonix). ’

Seems only the latter is possible now (or in DispVMs).

1 Like
2

Hi mig5

Configure an anon-whonix VM. Add all security settings to Tor Browser. Then clone anon-whonix and append the dvm tag the newly cloned VM’s name (i.e. anon-whonix-dvm). Then set prefs to template_for_dispvms true in anon-whonix-dvm.

1. Create the

Note: Tor Browser will not start if run from an AppVM with the dvm tag appended to name. For example, Tor Browser will not start in a VM named anon-whonix-dvm . However, a work around would be to create an AppVM without the dvm tag and use that for the intial custom configurations. Once that is complete, clone the AppVM with the dvm tag appended to the name.

qvm-create --class AppVM --template whonix-ws-14 --label red anon-whonix-temp

2. Set nevm to none since you should never connect to the internet using dvm templates

qvm-prefs anon-whonix-temp netvm ""

3. Start Tor Browser and add all custom security setting (Tor Browser, NoScript etc…) to Tor Browser.

4. Shutdown Tor Brower

5. Clone anon-whonix-temp and add the dvm tag the newly cloned AppVM

qvm-clone anon-whonix-temp anon-whonix-dvm

5. Set the newly cloned AppVM’s prefs to dvm

qvm-prefs whonix-ws-dvm template_for_dispvms true

6. Add dom0 menu entry for dvm

qvm-features whonix-ws--dvm appmenus-dispvm 1

7. Spawn a Tor Browser dispvm from the new whonix-dvm

8. Add all other setting ( bookmarks, HTTPSEverywhere rules etc) to the Tor Browser dispvm
9. Copy all pertinent files from Dispvm: /home/user/.tb/tor-browser/Browser/TorBrowser/Data/Browser/profile.default to the same location in the whonix-ws-dvm

Seems like the only way for most settings

1 Like
3

The reason for this:

(please press expand)

Is our reasoning valid or overly cautious?

tb-starter by Whonix developers (/usr/bin/torbrowser) is just a wrapper
to start Tor Browser. Advanced users may circumvent tb-starter. You
could start a DVM template konsole.

Then start Tor Browser from command line by not using torbrowser
(/usr/bin/torbrowser). (Similar Tor Browser Essentials
) Go to /var/cache/tb-binary folder.

Make your modifications. Shut down the DVM Template.

The /usr/bin/torbrowser function refusing the start can also be easily
overwritten using a /etc/torbrowser.d config snippet.

A safer / cleaner way to modify Tor Browser’s profile may be to not
start it but drop the appropriate config files.

Related:

1 Like
4

Thanks both, especially @Patrick as I didn’t realise there was a way to circumvent it for ‘advanced’ use.

I don’t think it’s overly cautious - already I suspect the DVM/TemplatebasedDVM stuff is confusing for most Qubes users, so it’s good to add some precautions.

I’ll see what is the easiest way for me. Obviously adding the config in directly without spawning TorBrowser is the ‘best’ way, but it’s so complicated config under the hood, not like a simple .ini or .conf file, that I may resort to setting it all up via the browser once-only and then copy the entire config dir if I need to do it again…

Actually @0brand’s method seems quite sane too (do all the work in a DispVM once, then copy the results back to the DVM template) :+1:

3 Likes
5

I ran into the same issue when I wanted to increase the default torbrowser security slider (the default allows javascript).

I think this may be insufficient, /var/cache/tb-binary is not a bind-dir in my dvm template, so any customization there will be lost. It may be necessary to start the browser in the template instead.

If the reason is to prevent correlation across identity VMs through seeing the mtimes of various files created on first-time use… It seems like in that case, the attacker would also be able to see the mtimes of files installed anywhere in the system, which would also be a unique signature tying together all VMs arising from the same template.

If the reason is to prevent net access from the dvm template from compromising it (and all its children)… wouldn’t a scary warning be sufficient on launching torbrowser (in VMs whose name ends in *-dvm)?

6

I correct myself:
Tor Browser / tb-updater is not supposed to be started in whonix-ws-14-dvm.

In TemplateVM:
Go to /var/cache/tb-binary go to Tor Browser folder. Manually start. Modify.
Does that work for you?
If so, could you document this please?
Qubes Disposables

Better since whonix-ws-14-dvm (or any Qubes DVM) is not yet non-networked by default.

This is already implemented.

7

If so, I don’t understand why this re-creation of the tb-binary is done?

It seems like there are no benefits:

  • already a warning against starting torbrowser in dvm
  • correlation prevention based on existance of files is undermined by dispvms sharing a bitwise-identical template VM root (unique mtimes of system files based on time of last apt upgrade, among other things).

There are only costs:

  • complexity: extra code to recreate the tb-binary (and home dir?)
  • inconsistent with other qubes dvm
  • confusion arising from change from whonix-13
  • forces dispvm customization to be done in the template (more security critical than the dvm template)

Unless this is a step towards more comprehensive anti-correlation in a future whonix (which would be awesome)? Or maybe I’m misunderstanding the attacker model - is the attacker only able to check for existance of files inside /home/user?

Edit: removed incorrect comment about multiple dvm templates

8

For TemplateBased AppVMs: Tor Browser copied from /var/cache/tb-binary, necessary since Qubes R4 TemplateBased AppVMs longer inherits TemplateVM’s folder.

Dev/Qubes - Whonix

Currently when updating Tor Browser in whonix-ws-14 TemplateVM (by installing an updated tb-updater package or through manually running update-torbrowser) will result in newly created TemplateBased AppVMs as well as whonix-ws-14-dvm based DispVMs coming with up to date Tor Browser.

[1] Given the limitations of Tor Browser (no deb package availably) this is already a feature rich, complete solution.

That comes from [1].

I don’t like carrying legacy around. Good implementations in new versions are better. Whonix 13 DispVM were for the most time discouraged.

It’s not really forced. By dropping config snippets, any behavior can be disabled.

What do you mean by re-creation?

The rationale is this (click to expand):
Tor Browser Advanced Topics

What extra code do you mean? Might be due to assuming TemplateVM home folder gets inherited by TemplateBasedVM? That’s why /var/cache/tb-binary complexity is required.

The only extra complexity would be allowing/encouraging users by default running update-torbrowser in whonix-ws-14-dvm, storing in home folder, allowing customizations in home folder. Then two different defaults.

(But non-inheritance of TemplateVM home folder in Qubes generally by TemplateBasedVM is very sane imo.)

All of this makes my head spin. For me it’s already complex enough. :slight_smile: (TBB as deb package would be a blessing.)

1 Like
9

I thought the old system (where you use the torbrowser downloader in each newly-created TemplateBasedVM and DVM template) is better, because in the new system, the wierdness of how torbrowser is installed (in the home folder) is accomodated by making the DVM templates and TemplateVM behave wierdly too (no longer do they exclusively manage the home folder and system files, respectively). This is just a matter of opinion though.

I’m not sure what this means? But as 0Brand mentioned, one can disable the behavior by naming their DVM template something other than *-dvm.

I only meant first-boot-home-population in new dispXXX instances running to create a fresh torbrowser, rather than the old way of using a torbrowser downloaded to (and customized in) the DVM template’s home folder. I understand now this is part of the implementation to constantly update torbrowser from TemplateVM.

1 Like
10

That is more of a hack than valid instructions. In the future a proper check will be used that does not check for “dvm” in the name.

I’m currently working on documentation for Qubes-R4 Whonix-14 disposableVMs. I could use some help (If you have the time :slight_smile: )

1 Like
11

As you can tell, I’m not exactly a fan of how dvms are implemented in whonix-14, so I’m not sure I’m the right person to go writing about them… I guess I can give things a read-through, making use of my limited knowledge of them?

1 Like
12

And I want to orwell style rewrite history removing that idea from existence. :wink:
The scripts are flexible enough to allow such configs.
DVM Templates without DVM in its name create another level of complexity. So much complexity that even I as a developer don’t manage anymore to see through if some time passes and questions/issues come later. Also it breaks once a clean API by Qubes is provided to detect a DVM by proper means qubesdb-read rather than its name.

I’m not sure what this means?

Just now documented here: Tor Browser Advanced Topics

1 Like
13

I’m not sure which scripts this refers to

The base qubes system seems very elegant to me (correct me if my understanding is wrong):

  TemplateVM     TemplateBasedVM  DispVM
     root    <-------- root <----- root
     home              home <----- home
  • TemplateVMs has own root, has own home.
  • TemplateBasedVMs get their root from the parent TemplateVM, have own home.
  • DispVMs get their root from the grandparent TemplateVM, gets their home from a TemplateBasedVM.

Naturally:

  • the DIspVM is stateless
  • the DispVM’s root is managed by the TemplateVM, and its home is managed by the TemplateBasedVM.

I think “DVM template” doesn’t exist as a separate VM class anymore in r4, it is nothing more than a TemplateBasedVM with the template_for_dispvms property and the appmenus-dispvm feature.

If nothing special is done, then since Torbrower is installed in ~/.tb, it would be managed with the rest of the home folder by the TemplateBasedVM.

You’d have very natural workflows:

  • To update TorBrowser in the DispVM, run torbrowser downloader in each DVM template.
  • You can have torbrowser v7.5 for one DispVM and torbrowser v8.0 in another DispVM, by just choosing the appropriate version when running TorBrowser downloader in the parent DVM Templates.
  • launching TorBrowser in a TemplateBasedVM with template_for_dispvms property brings up a scary message warning against customization, maybe suggesting drop-in config snippets as an alternative.
  • but if the user wants to customize TorBrowser at his own risk, he disregards the message. He can have a low-signature DVM template with factory settings, a hardened but higher-signature DVM template with javascript disabled by default, another DVM template with ublock origin installed to minimize 3rd-party requests, etc…
14

tatertot:

I’m not sure which scripts this refers to

All Whonix packages generally but specifically here : tb-starter /
tb-updater

The base qubes system seems very elegant to me (correct me if my understanding is incorrect):
TemplateVM → TemplateBasedVM → DispVM

  • TemplateVMs own root, own home.
  • TemplateBasedVMs get their root from the parent TemplateVM, have their own home.
  • DispVMs get their root from the grandparent TemplateVM, get their home from a TemplateBasedVM.

Looks correct. Dev/Qubes - Whonix

Naturally:

  • the DIspVM is stateless
  • the DispVM’s root is managed by the TemplateVM, and its home is managed by the TemplateBasedVM.

I think “DVM template” doesn’t exist as a separate VM class anymore in r4, it is nothing more than a TemplateBasedVM with the template_for_dispvms property and the appmenus-dispvm feature.

Yes.

If nothing special is done, then since Torbrower is installed in ~/.tb, it ought to be managed with the rest of the home folder in the DVM Template.

ought is a strong word here.
If nothing special is done, Tor Browser does not come preinstalled
anywhere and the user has to manually download it for each VM as it was
in the first Qubes-Whonix version.

You’d have very natural workflows:

  • To update TorBrowser in the DispVM, run torbrowser downloader in each DVM template.

So there would be complaints / feature requests to update it twice: In
TemplateVM and in (each) DVM Template.

Starting the DVM template has bad usability currently.

  • You can have torbrowser v7.5 in one DVM template and 8.0 in another, by just choosing the appropriate version in the TorBrowser downloader.

True. (You are still able to have that currently by the drop-in configs
referenced in my last post.)

On the other hand for most normal packages from Debian you don’t have
that flexibility to pick your version either. Well, maybe you can
install them in home or /usr/local maybe but Whonix doesn’t stop you
from that either. Manual installation and start of Tor Browser is doable
just the default tb-updater / tb-starter is in question.

  • launching TorBrowser in a TemplateBasedVM with template_for_dispvms property brings up a scary message warning against customization, maybe suggesting drop-in config as an alternative.> * but if the user wants to customize TorBrowser at his own risk (e.g.
    increase default security slider), he disregards the message.

There is certainly room to improve the current popups if you meant that.
I am wondering now if we should even make it a yes/no button. Even one
time only yes/no buttons are conceivable. (Easier than current drop-in
config method.)

15

I may have incorrectly assumed the torbrowser downloader installs into the home folder, where the final torbrowser resides.

To be clear, you mean there would be dueling feature requests?
(1) feature request to be able to update torbrowser in the TemplateVM just like other software
(2) feature requests like mine to be able to update it in the DVM template

I completely agree, AFAIK the easiest way to do this is to do qvm-run whonix-ws-14-dvm torbrowser. Or disable appmenus-dispvms feature and use the appmenu, and have a shortcut button for actually launching dispvms.

At least people may be used to this since it’s the same procedure for non-whonix DVM templates; at least its not surprising.

Agree.

I just mention the pop-up to assuage concerns about server-detectable customizations reducing anonymity to pseudonymity.

16

Based on the final resting place of ~/.tb in home, one would expect the TemplateBasedVM / DVM template to be the place to customize it, like the rest of the home folder.

I think it is a little surprising/unnatural that ~/.tb in home (the purview of the TemplateBasedVM / DVM Template) came from /var/cache/tb-binary (the purview of the TemplateVM), and he has to go to the latter VM to customize it.

17

tatertot:

I may have incorrectly assumed the torbrowser downloader installs into the home folder, where the final torbrowser resides.

I meant with “If nothing special is done, Tor Browser does not come
preinstalled” - if nothing special is done - tb-updater / tb-starter
doesn’t exists which are just hacks around a missing TBB deb package.

To be clear, you mean there would be dueling feature requests?
(1) feature request to be able to update torbrowser in the TemplateVM just like other software
(2) feature requests like mine to be able to update it in the DVM template

There are indeed.

(1) is understandable to make it “deb like”

(2) is quite geeky

I just mention the pop-up to assuage concerns about server-detectable customizations reducing anonymity to pseudonymity.

We currently only have these for Tor Browser.

18

tatertot:

Based on the final resting place of ~/.tb in home, one would expect the TemplateBasedVM / DVM template to be the place to customize it, like the rest of the home folder.

I see.

I think it is a little surprising/unnatural that ~/.tb in home (the purview of the TemplateBasedVM / DVM Template) came from /var/cache/tb-binary (the purview of the TemplateVM), and he has to go to the latter VM to customize it.

It will always be messy in the absence of a TBB deb one way or another.

Without it coming from /var/cache/tb-binary:
Imagine a first time user trying to run a Whonix based DispVM without
any DVM Template customizations beforehand. Result: Tor Browser not
installed.

19

Since a premade DVM template is provided by whonix, it can include a copy of torbrowser pre-downloaded to the home folder.

20

Would just need to remove that code:

if echo "$qubes_vm_name" | grep -q "\-dvm" ; then
   exit 0
fi

From here:

https://github.com/Whonix/tb-updater/blob/master/usr/lib/tb-updater/first-boot-home-population#L23