Qubes DispVM technical discussion

Qubes-Whonix
13

Any thoughts on the (previously existing) quote Tor Browser Essentials

Don’t start Tor Browser in the whonix-ws TemplateVM or whonix-ws-dvm DisposableVM-TemplateVM. It is not expected to be done that way and wrong. […]

14

I am in process of of working through the wiki edits by @entr0py . For now only stylistic changes. Feel free to discuss these. For example I don’t like the two new lines so much. If you think that a more visible separate was useful we could add ----- (which results in and is the same as <hr>. (As I did for some tunnel documentation.)

15
16

Under the Qubes TemplateVM model [1], any changes made to a TemplateBasedVM’s root filesystem are lost upon reboot. This can be advantageous from a security viewpoint since malicious code installed to the root filesystem is discarded prior to the next session.

(On TemplateBasedVM) I somewhat disagree with the latter sentence. This would work indeed against off-the-shelf malware that targets general Linux and installs itself lets say as a rootkit in /etc somehow. It would not work against off-the-shelf malware with “Qubes support” let alone for tailored malware.

Also Qubes doesn’t declare that as security feature. What an security feature is, that if one TemplateBasedVM is compromised (considered a permanent compromise until that TemplateBasedVM gets purged), is that it cannot spread to the TemplateVM or other TemplateBasedVMs.

Therefore I removed that sentence.

1 Like
17

Quote Qubes Disposables

Qubes does not have a built-in snapshot capability like VirtualBox that
can completely revert all changes back to a particular VM state.

True. Added a footnote:

Apart from [https://www.qubes-os.org/doc/dom0-tools/qvm-revert-template-changes/ qvm-revert-template-changes] which can only revert back prior the previous (not last) shutdown of the TemplateVM.

And another footnote:
https://forums.whonix.org/t/qubes-vm-snapshots-using-git-svn

1 Like
18

The conservative view would be to recommend that as a best practice. However, we are already relying on Tor Browser not to generate any unique identifiers every time we use it. So logically, it should be safe to run in a template for customization purposes. But it really needs to be stressed that customization is a dangerous exercise. For example, I found by accident that a seemingly innocuous change:
NoScript -> Options -> Notifications -> check 'Show message about blocked scripts'
will alter reported screen size when JS is enabled.

1 Like
19

Agreed! Please add!

I haven’t forgotten to answer your questions in.

Good question. Next question. :slight_smile:

My advice now is “check your Tor Browser version and make it work”:

Qubes Disposables

20

So far so good! Great work!

I am done editing on top of your changes and suggestions for now. Made lots of nitpick edits and also real enhancements.

Now, having it documented so far, using hardened Tor Browser in [customized] DispVM is not that hard? In case of issues just use update-torbrowser in DisposableVM-Template. Please feel free to add it. Then use Qubes Disposables.

As for adding instructions for hardened Tor Browser version vs complexity, I think there is an acceptable solution. Use the expand button. See example Whonix mediawiki markup using expand buttons.

I guess this is as far as we can reasonable get with Qubes R3.2 without going into a lot more effort and gymnastics.

Let’s post this sometime soon on qubes-devel? And afterwards also on Whonix blog and qubes-user?

21

I’m not sure what that is. I do prefer more whitespace to less. For example, Tor Browser Essentials has gotten difficult to read. Part of the reason also is because = Heading = is too big relative to body text and should only be used sparingly for main chapters. I prefer ==== Heading ==== to divide subchapters.

22

I understand why this warning is necessary - namely, there is no way to enforce the behavior that we want.

On the other hand, users shouldn’t be scared into thinking that the process is somehow unpredictable or inherently risky. If directions are followed, there is virtually no chance of using an out-of-date or wrong Tor Browser version. I started using Whonix DispVMs when I wrote my first post in the other thread nearly 7 months ago. Since then (as far as I can remember), I’ve only updated my Tor Browser using the Internal Updater, which pops up within a few seconds of launching Tor Browser in any DispVM. In fact, the annoyance of the pop-up leads one to update the DisposableVM-Template as soon as possible.

Related note: The default update setting in TB preferences is to update automatically. I set mine to notify-only since having every DispVM update automatically is annoying x2.

23

Added instructions for TBB-alpha. Alpha users are grown-ups so they only get cli. Used the expand button with a separator at the bottom - would be nice to be able to put the whole expand section in a box.

Added some nitpicks back at ya. It’s ready to go I think. I wonder if stylometry algorithms can pick up multiple writers.

Of course, this is not considering the results of Application Customization and Privacy Issues. Hope that doesn’t necessitate a rewrite. :confused:

24

@Patrick @entr0py

You’ve done an amazing job on the wiki entry! Well done to both of you.

Tester Report on Wiki Entry Correctness (Qubes 3.2)

From a clean state:

  • Creating a fresh Whonix-WS dispVM works;
  • Adding the Tor Browser and Konsole entries to the XFCE menu for dispVM works;
  • Tor Browser XFCE entry successfully launches within the Whonix-WS dispVM;
  • The customized Whonix-WS dispVM remembers Javascript, slider and add-on changes with the touch command for the standard 6.0.7 Tor Browser (well done!);
  • cli commands for updating the customized Whonix-WS dispVM to reflect the preference for the 6.5a5-hardened browser works; and
  • Re-running the touch commands to customized settings for the hardened Tor Browser also works (even better!).

100% success!

Wiki Small Typo

Change:

If you intent to spawn DisposableVMs from other VMs

→

If you intend to spawn DisposableVMs from other VMs

Suggested Additions

One x additional footnote in the ‘Updating Tor Browser’ section (somewhere):

Prior to installing the Tor Browser in the DisposableVM-Template, check the Tor Project signing keys match those found online at: How can we help? | Tor Project | Support

&

Edit footnote 28 to say:

Advanced users can also select the hardened Tor Browser at this step before recreating the DisposableTemplateVM.

1 Like
25

entr0py:

I understand why this warning is necessary - namely, there is no way to enforce the behavior that we want.

On the other hand, users shouldn’t be scared into thinking that the process is somehow unpredictable or inherently risky. If directions are followed, there is virtually no chance of using an out-of-date or wrong Tor Browser version. I started using Whonix DispVMs when I wrote my first post in the other thread nearly 7 months ago. Since then (as far as I can remember), I’ve only updated my Tor Browser using the Internal Updater, which pops up within a few seconds of launching Tor Browser in any DispVM. In fact, the annoyance of the pop-up leads one to update the DisposableVM-Template as soon as possible.

Related note: The default update setting in TB preferences is to update automatically. I set mine to notify-only since having every DispVM update automatically is annoying x2.

I guess you are not just referring to the specific “check Tor Browser
warning” but also the general “Advanced users only!” warning at the very
top of that wiki page?

Sure. I am all for describing things as close to The One Truth ™ as
possible. If you see a way to rewrite the warnings so they sound more
accurate, please go for it.

My intention with the general “Advanced users only!” warning is just to
make sure users read these documentation before using DispVMs. Then
DispVMs are great. However, just “qvm-create-default-dvm” and then use
Firefox in the DispVM and expect anonymity is a failure I like to prevent.

26

entr0py:

[quote=“Patrick, post:14, topic:3232”] I don’t like the two new lines
so much. [/quote]

I’m not sure what that is.

It is:

text


other text

What about rather using a dividing line (which also results in enough
white space)?

text
27

torjunkie:

You’ve done an amazing job on the wiki entry! Well done to both of you.

Thanks! Also of to thank you! :slight_smile:

I’ll try your ‘untested’ entries to check they actually work with Qubes 3.2 eg XFCE menu entries and so on.

That’s great!

28

No, I was just pointing out that updating TB in a DispVM-Template works reliably. I agree with Advanced User Warning because current state of DispVMs is ambiguous, messy, difficult to understand completely.

My preference right now I think is:

---- ;separator
## Main Chapter ##
#### Sub Chapter ####
##### Main Steps #####
''' Sub Steps ''' ;don't need to be indexed
---- ;separator

also, separators with expand sections, because it’s hard to tell where they end.

1 Like
29

Sounds good!

todo: needs resolution of tb-updater experimental --alpha, --beta, --rc, --hardened options - #3 by Patrick

I don’t think so. In Whonix 13 it does not matter since tb-updater shows all Tor Browser versions anyhow. It matters for Whonix 14. So in meanwhile this can be removed from DispVM documentation. [And I guess for Whonix 14 it’s best to keep it like in Whonix 13.]

Yes.

For chapter Qubes Disposables I was wondering… To make the separator more visible, what about another

'''headline'''

before the text for non-advanced, regular users starts? Any idea for a headline?

30

Done. Looks better.

Are you suggesting removing Option #1 entirely? The point of that option is that it should be a simpler method for TBB-alpha users who don’t want a customized DispVM-Template. Also, they’ll probably be making the appropriate changes to whonix-ws anyway so they can have TBB-alpha in their AppVMs. However, I’m not even sure if it works. That was the reason I asked Qubes DispVM technical discussion - #10 by entr0py.

Reasons to get rid of Option #1 even if it works:

  1. @torjunkie confirmed that Option #2 works. and advanced users would probably want customization enabled so they can keep changes for testing.
  2. (IIUC) Option #1 would require recopying TBB from /var/cache every time a change is made to whonix-ws; for example, due to daily update maintenance. Probably not a big deal.
31

No. Just the sentence todo: needs resolution of https://forums.whonix.org/t/tb-updater-experimental-alpha-beta-rc-hardened-options/781/3 gotta be replaced with real content.

32

entr0py:

The point of that
option is that it should be a simpler method for TBB-alpha users who
don’t want a customized DispVM-Template.

Sounds reasonable.

Reasons to get rid of Option #1 even if it works:

  1. @torjunkie confirmed that Option #2 works. and advanced users
    would probably want customization enabled so they can keep changes
    for testing.

I don’t think all advanced users want DispVM customization. I add myself
to that group. :slight_smile: