Qubes DispVM technical discussion

Qubes-Whonix
34

Ah, great, thanks for summarzing it!

Right.

(I am keeping releasing tb-updater package upgrades with bumped (stable) hardcoded version numbers (tbb_hardcoded_version), because I am not trusting the auto detection is going to work forever. When RecommendedTBBVersions format changes as it did a few times in past, the version auto detection breaks. [tbb_hardcoded_version is set to the stable, since That is the recommended version by Torproject, most stable, least maintenance overhead.])

Another future feature could be to ship two versions of tbb_hardcoded_version. One for default, for most, for stable users and another one with the most reasonable alpha (would be now: hardened). I didn’t go for this, because it would increase maintenance overhead. (More tb-upgrader stable upgrades, not only for new stable Tor Browser releases, but also for each new alpha.)

An alternative additional(!) future feature [disabled by default] could be to auto detect the highest available version number of a configurable release channel (terminology used by Tor Browser about menu) (for example: stable or hardened). tb-updater would also need a feature to auto run. But when, and how(!) would in Qubes TempalteVMs be a good time to auto run? The how is a big question mark. There are no hooks into apt-get update or apt-get dist-upgrade. Only dpkg hooks. And running tb-updater every time dpkg runs seems wrong.

Right. I don’t see any way around that as of Whonix 13. And for Whonix 14, we’d still need to draft a feature (as per above).

As of Whonix 13 without any of the features described above, I think tb_install_follow=false should be mandatory for anyone wanting to use hardened. (With a reminder to recheck for Whonix 14. Maybe we’ll think of something.)

Please add.

1 Like
35

Sure?

sudo dnf install xfdesktop

Why not qubes-dom0-update?

Quote marmarek:

In principle it will be possible to start an AppVM in “disposable”
mode - which means changes to its private image (in addition to root
image as in normal AppVM) will be discarded after VM shutdown.
Technically any AppVM can be used for that, but practically it makes
sense to have dedicated “DispVM template” AppVMs (as currently
fedora-xx-dvm).

This will be so awesome! Fix most of the complications we are facing.

36

No, that’s not right. Result of not being able to test my own instructions. Plus, that step can be omitted completely if xfdesktop is installed automatically by Qubes dom0, which most likely it is - but I can’t check.

Please see if xfdesktop is already installed on your 3.2 system, then we can remove that step.

Also, if you are willing, there will be a new set of untested instructions in the ‘Expand’ section of Qubes Disposables under Option #1.

Thanks!

1 Like
37

I can confirm xfdesktop was installed for me already.

Yes. Please do. Going easy on regular users and going hard on advanced users and testers. The Only Way ™ forward.

38

Qubes-Whonix DisposableVM documentation created blog post public preview:

Any feedback?

Please sign up for the wiki (and tell me your account name so I can upgrade it) if you like to edit that blog post or post other stuff.

1 Like
39

Perhaps paraphrase relevant content from the wiki, Qubes docs and Joanna, so that normal users understand the point of using a Whonix-WS DispVM.

Recommended blog change:

Before we had just a stub. Now, Qubes-Whonix DisposableVMs are fully documented thanks to contributions by the community.

What are DisposableVMs?

Under the Qubes TemplateVM model, any changes made to a TemplateBasedVM’s root filesystem are lost upon reboot. This is advantageous for several reasons: it allows centralized (and therefore faster) updates for all applications (most) inside the root filesystem, saves time and disk space.

However, certain directories are designed to persist between reboots in order to store files and settings. These directories are stored in /rw/ and include /home/user as well as additional directories defined by “bind directory” settings.

To ensure that all changes to the filesystem are discarded after a session, Qubes offers DisposableVMs. When a DisposableVM is shutdown, the VM is removed from Qubes and all related VM images are deleted from the host filesystem.

What is a Whonix-Workstation DisposableVM?

As the name suggests, this is a Qubes DisposableVM template based on the Whonix-Workstation. This allows Qubes-Whonix users to create throw-away instances of their Whonix-Workstation.

Importantly, the Whonix-Workstation DisposableVM will inherit the netVM and firewall settings of the ancestor VM by default, meaning the Whonix-Gateway will be safely used.

Why Should I Consider Using a Whonix-Workstation DisposableVM?

Whonix-Workstation DisposableVMs:

  • Are quickly generated;
  • Are disposed of (deleted) when the user has finished browsing and other activities in a single session; and
  • Will not remember any of the user’s activities across DisposableVM sessions, unless customized.

The major benefit of this approach is that the Whonix-Workstation DisposableVM can be created in order to host a single application - usually the Tor Browser - without any risk that a compromise of the browser will effect any of your other VMs.

Critically, a Tor Browser exploit will not effect (poison) later instances of the Tor Browser running in a subsequent DisposableVM session, because the DisposableVM is always started in a clean state.

Can I Customize Whonix-Workstation DisposableVMs?

Yes. For advanced users, the instructions include steps to create a customized savefile that will remember specific changes, such as personalized Tor Browser settings. Due to concerns over possible fingerprinting issues, users should carefully read the wiki warnings before proceeding on this course of action.

Can I Easily Add DisposableVM Entries to the Qubes Menu?

Yes. Steps have been included which successfully create entries to the XFCE4 menu in Qubes 3.2.

What Else Should I Know?

Due to a few usability issues affecting anonymity, do not use Whonix-Workstation DisposableVMs until:

  • You understand Whonix-WS DispoableVMs are NOT yet amnesic; and
  • Have carefully read and understood the available Qubes-Whonix DisposableVM documentation.

Alternatively, you may wish to wait for Qubes 4.0 [1] before you start using Qubes DisposableVMs, due to significant enhancements planned for the later release.

2 Likes
40

Amazing work!

Do you mean chapter Qubes 3.2 / XFCE4 - menulibre (untested) by that? If so, the (untested) should e removed from the wiki.

Since chapter Qubes 3.2 / XFCE4 - menulibre (untested) modified whonix-ws-dvm /home/user, doesn’t it require using a customized DispVM, i.e. /home/user/.qubes-dispvm-customized?

41

Unless there are other comments, I think the blog post is almost ready to go. Updated the preview:
News - Whonix Forum

The only thing I would like to sort out before posting it are my above questions since otherwise it would contradict.

Yes. Steps have been included which successfully create entries to the XFCE4 menu in Qubes 3.2.

if XFCE4 menu was replaced by “desktop shortcut”, it would be ready to go.

42

Careful here lest users ignore the warning in the wiki. Ancestor VM if called from dom0; Calling VM if spawned from domU. This is actually a weakness of current implementation.

Looks good!

A couple conservative wording changes:

The major benefit of this approach is that the Whonix-Workstation DisposableVM can be created in order to host a single application – usually the Tor Browser – without any risk that a compromise of the browser will effect any of your other VMs.

“without any risk” > “mitigating the risk”

Critically, a Tor Browser exploit will not effect (poison) later instances of the Tor Browser running in a subsequent DisposableVM session, because the DisposableVM is always started in a clean state.

“effect” > “affect”

“in a clean state” > “in its original state”

1 Like
43

Thanks entr0py. Agree with your changes. My old English teacher will kill me if they saw effect and affect mixed up again :wink:

@Patrick, I was referring to steps for changes to the Qubes menu as ‘working’ i.e. Qubes Blue/Gray Button -> DisposableVM -> (new) Tor Browser entry

That is, replacing the instance of ‘Firefox’ from the DispVM menu with Tor Browser instead.

Sorry, I didn’t get around to trying the the menulibre entry as I had promised earlier. So that is still ‘untested’, unless you have it working. I’d still like to try those untested steps sometime over the next week, so that ‘untested’ can be removed from the wiki entry.

But please go ahead and put up your blog post if you are happy with everything else.

1 Like
44
1 Like
45

“effect” still needed to be changed to “affect” in that blog post :wink:

Anyway, I have tested Option#1 of generating a non-customized DisposableVM-Template which works.

So, you can remove the “untested” tag from the wiki here:

Option #1: Use a non-customized DisposableVM-Template. (untested) This template will use a stock image based on whonix-ws and will not preserve any changes that are made to it.

Re: “Adding shortcuts to applications menus”, which is also untested in Qubes 3.2, I have followed the steps up to this point:

Once the .desktop files have been created, they need to be added to your Applications menu. Use a text editor to edit the following file.

kwrite ~/.config/menus/xfce-applications.menu

Note: There is NO xfce-applications.menu entry anywhere in the template. I have searched using find and ls to no avail. Using kwrite as above just creates a new (empty) file.

Surely Marek knows where this (.menu file) is stored for dispVM template in the Qubes architecture? After all, the entry for the original DispVM menu can be edited to replace Firefox with the Tor Browser entry instead via Alt F3 in dom0.

So where is it? Adding the additional .desktop entries should be simple enough. Maybe he can give us some pointers.

I have not attempted the menulibre option, as I don’t want to bork my menu as per other people’s recent experiences.

1 Like
46

You mean dom0 right?

This is the reference I used for instructions: howto:customize-menu [Xfce Wiki]

Things to try:

  • sudo find / -name *.menu
  • echo $XDG_CONFIG_HOME
  • looks like default install location is /etc/xdg/menus/xfce-applications.menu
    Instructions say to make a copy in ~/.config/menus for customization
1 Like
47

Fixed.

Done.

48

If you get comfortable with git (and virtual consoles, was not even required for me), you can easily rewind any changes by non-root applications such as menulibre that are only writing into the home folder.

49

All in dom0 /home/user.

Seems like some .desktop file is required in .local/share/applications. Example:
.local/share/applications/qubes-dispvm-firefox.desktop

And qubes-dispvm-firefox.desktop is referenced in:
.config/menus/xfce-applications.menu

I guess these are the files to edit by emulating how its done with the two above files. A word of caution: I managed to loose my system settings Qubes start menu entry by just adding a new desktop file to .local/share/applications/.

50

What if you cp /etc/xdg/menus/xfce-applications.menu ~/.config/menus/ first?

1 Like
51

That restored my system settings Qubes start menu entry.

/etc/xdg/menus/xfce-applications.menu mentions DefaultMergeDirs. That may be a lead for investigation. DefaultMergeDirs to me implies it may be possible to extend the start menu without having to directly edit ~/.config/menus/xfce-applications.menu (by editing some other file).

52

XFCE follows the freedesktop standard. The DefaultDirs are explained here: Desktop Menu Specification. These Dirs specifiy locations to look for .menu (MergeDir), .directory (DirectoryDir), and .desktop (AppDir) files.

I decided to stop being an idiot and went to look for the Qubes .menu file. From this: qubes-desktop-linux-xfce4/garcon/garcon-0.2.0-qubes-menus.patch at release3.2 · QubesOS/qubes-desktop-linux-xfce4 · GitHub, it looks like Qubes is pulling in .menu files from some applications.d directory. Best guess for location would be one of $XDG_DATA_DIRS, so maybe /usr/local/share/applications.d/. That must be where each VM has its own .menu file. If you can locate the DispVM-like.menu, then it should just be a matter of adding custom .desktop to the <Include> section.

1 Like
53

Thanks to both of you. I’ll play around with this and see if I can work it out.

2 Likes