[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Qubes DispVM technical discussion


#46

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
  • 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

#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?


#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: 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.


#53

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


#54

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


#55

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 (?)

https://www.qubes-os.org/doc/dispvm-customization/

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]
Version=1.0
Type=Application
Exec=sh -c 'echo arbitrary | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red
Icon=dispvm-red
Terminal=false
Name=DispVM: Arbitrary Name
GenericName=DispVM: Arbitrary Generic Name
StartupNotify=false
Categories=Network;X-Qubes-VM;

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.


#56

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


#57

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
    https://github.com/QubesOS/qubes-issues/issues/3201

#58

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

Questions:

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

Related:

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


#59

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.

https://phabricator.whonix.org/T725#14729


#60

#61

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


#62

Yay!

https://www.whonix.org/w/index.php?title=Qubes/DisposableVM&oldid=34035&diff=cur


#63

#64

#65

Major update of documentation for DispVMs for Qubes R4 with Qubes-Whonix 14.

Has still quite some TODOs. Help welcome.

Bold changes. Lots of purges. If anything got missing in action it can be recovered from https://www.whonix.org/wiki/Deprecated#Qubes_DisposableVM or from wiki history.


Long Wiki Edits Thread