Qubes DispVM technical discussion


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.



“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.


You mean dom0 right?

This is the reference I used for instructions: https://wiki.xfce.org/howto/customize-menu

Things to try:

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





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.


All in dom0 /home/user.

Seems like some .desktop file is required in .local/share/applications. Example:

And qubes-dispvm-firefox.desktop is referenced in:

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/.


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


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).


XFCE follows the freedesktop standard. The DefaultDirs are explained here: https://specifications.freedesktop.org/menu-spec/menu-spec-latest.html#paths. 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: https://github.com/QubesOS/qubes-desktop-linux-xfce4/blob/release3.2/garcon/garcon-0.2.0-qubes-menus.patch, 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.


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


How timely… if anyone is looking to become an expert in Qubes appmenus… https://groups.google.com/d/msg/qubes-devel/nR_VRLX6FPc/JDoWwKkBDgAJ


We should test these Qubes instructions for DispVM customization and then replace the existing (untested) instructions we have for DispVM menu customization.

I presume everything is the same as below, except references for usr/share/applications is replaced by ~/.local/share/applications for Disp Whonix-Workstation VMs (?)


Adding arbitrary programs to Disposable VM Application Menu

For added convenience, arbitrary programs can be added to the Application Menu of the Disposable VM. In order to do that arbitrary.desktop file has to be created in /usr/share/applications in Dom0. That file will point to the desired program. Use following template when creating a .desktop file:

[Desktop Entry]
Exec=sh -c 'echo arbitrary | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red
Name=DispVM: Arbitrary Name
GenericName=DispVM: Arbitrary Generic Name

Next, the /etc/xdg/menus/applications-merged/qubes-dispvm.menu file has to be modified so that it points to our newly-created .desktop file.

Add arbitrary.desktop line to the block. The modified file should look like this:

qubes-dispvm-firefox.desktop qubes-dispvm-xterm.desktop arbitrary.desktop

After saving the changes our program should appear under the Disposable VM Applications menu.


For Qubes R4 there have been quite some changes that need catching up:


Things are “starting” to get confusing :grinning:

                     inheritance (on create)     persistence (on poweroff)
TemplateVM           n/a                         everything
TemplateBasedVM      /etc/skel/ to /home/        /rw/ (includes /home/ and bind-dirs)
DispVM               /home/                      nothing

Conceptually, dispVM is now more flexible/convenient than before but potentially less anonymous since they are based on templateBasedVM and not templateVM - meaning there are more opportunities to configure them badly.

Potential tickets:

  • tb-updater needs to copy new TBB to /etc/skel/ instead of /home/user
  • set updateVM to sys-whonix-dispVM;
    or better but less usable: create new disposable-serviceVM to handle updates & non-random clockVM; attach to netVM: sys-whonix; disable update proxy in sys-whonix


//cc @marmarek Please have a look the post above mine.

It’s a nice table! @entr0py Perhaps add DispVM template or is it the same as TemplateBasedVM?

Could you please add the table to Whonix or Qubes wiki? (The latter would be better since it specific to Qubes, not Whonix. However having this table anywhere for reference would help a lot.)


  • When trying to start a DispVM for the first time, it actually starts the DispVM template such as whonix-ws-dvm. After shut down, using the very same shortcut to start the DispVM, it starts an actual DispVM starting Disp[...]. The user may be confusing the DispVM template for the actual DispVM since there is no graphical explanation what is happening. Is that right? If so, shall we open a usability bug?

  • How to start the DispVM Template (such as whonix-ws-dvm) for a second or subsequent time?

It’s maybe not ideal to introduce sys-whonix-dispVM as UpdateVM. That would hopefully only be an intermediary solution if anything. (As per this)

Could a whonix-ws based DispVM act as UpdateVM? Does that even require development on the Whonix side? (UpdateVM might work out of the box? Qubes updates proxy likely not?)

Hm. Good question. Still trying to wrap my head around it.


Based on that, what about the following implementation?

    1. Don’t run tb-updater-first-boot.service in TemplateVM. (Already implemented.)
    1. Don’t run tb-updater-first-boot.service in DispVM Template. How could being run inside DispVM Template be detected from within the first-boot-home-population script? @marmarek
    1. Copy from /var/cache/tb-binary to user home. (Already implemented.)
  • –> That would result in whonix-ws-dvm based DispVMs inheriting upgraded versions of Tor Browser if the tb-updater package in whonix-ws TemplateVM gets upgraded. That would spare the user from having to run tb-updater inside whonix-ws-dvm, which really wouldn’t be great to require (one VM more to update, one more complication).


Awesome, in Qubes R4, we can have a whonix-ws based disposable AppVM acting as UpdateVM as @marmarek pointed out. Sounds not too difficult, but I haven’t tried it yet.




In short: in Qubes-Whonix 14 after upgrades new AppVMs and DispVMs are created with a copy of the latest version of Tor Browser after tb-updater in whonix-ws TemplateVM was upgraded.

tb-updater and /usr/bin/torbrowser will refuse to start in Qubes DVM Template. (Advanced users could overwrite the function easily using a config snippet but I doubt there is a use case.)