Best practices?

[dexint...@gmail.com]

Just recently installed Qubes being new to Linux altogether I haven’t quiet developed my own best practices and the documentation online has a pretty steep learning curve. Anyway I was wondering what do you guys usually perform after a clean install. What do you do on a weekly basis, monthly, annually etc? How do you optimize Qube OS or is it already pretty optimized?

[22...@tutamail.com]

A clean install...you'll never feel more secure:)

A couple of best practices I would suggest include:

1) Clone your templates(maybe multiple cloned templates) and never install or use your original templates (This will help keep them secure and if you screw up on a clone you can always delete it and start a new clone from the original template)

2) Think about how you want to divide your different digital lifestyle/compartments e.g. email, banking, personal, work, passwords, etc...

3) What software do you need to install(if any)? Depending on your needs and uses e.g. LibreOffice, plugins, other Linux software? Install those on your cloned templates

Maintanence:
1) Keep your templates updated (and Dom0 updated)...this should be done right after an install
2) Backup your data and system weekly/daily (depending on your need)

Other security setups:
Set up a VPN
Explore minimal templates
Review BIOs
TPM
Look at your firewall and restrict IPs based on the Appvms use
Customize your DVM (disposable VMs)

Welcome and good luck! I never used Linux and I fumble thru fine after a little practice. Don't be scared to post a question after searching if you get stuck.

Keep your plugins, if any updated

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Take a look at this page, if you haven't already:

https://www.qubes-os.org/doc/security-guidelines/

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlxy+/cACgkQ203TvDlQ
MDBNChAAuqB56ZEUGJMS53K85SVJrs1QQrYC62eDDDorLW8IZ6U+6qh1YakL05+K
dDv1taa/wL70ipnwO0fQaFJurAMryYZ0twHNfZg5gJsTVK9gSgGkQdoAeePc0Bhr
7kx7jpELajdHAiK+idTvXR0A8Gpqu1aA37D+nVjEFNGhouHD8yHT3nltnjLaxiC+
FftreprJP/ot8OZ5klxDi6epVtCUy85Oi9t50wdPI9NUCGQYILqxbmENuzZBLCx/
uSRo7U7PboEKNbCGEVSXtKnGMcs6U9UyAAifOiHiHN+QznA+gOuc9EfyOAxm3/L8
zKYJMJ1dQwQ9SL1i2JuJc5pxjO/6CL8yH6l7mX1mXnVVmzxrDTDojJWeUwlF03nM
ek9/ufAFiE+6ztkZmKRwJAGfwW6B4uyxG27c6c85MxeZ9BcIQb+M5PEB8XQV4+79
OvXRtxiEQ4YVKCGbn4dyRRRyO40HcTRNqOwHzV4i2ubI46GS2jvMBLidxbXX4UKs
MUBQ5CFVPQP8Y7CB+6+KKRwEDUorqA/zhYaC3RumMuSUHmMGaJGCUq8Dl1EF9sS9
rFKwZmTkwTMm9P7NVYazHfYtNvTUVnJk0JAP5he9MotEMrP8pU4UC59m+cGBX8SY
EpAiahASBFEqnL2g8KY6pCDVSWmZ0lywcDOqogyc9hE/i/phQL4=
=fFLo
-----END PGP SIGNATURE-----

[22...@tutamail.com]

Important maintenece best practice:

...back up your data prior to updating dom) and your templates. I got burned on that a while ago.

[dexint...@gmail.com]

In terms of cloning the templateVMs should I be using the clone to create appVMs then?

[awokd]

dexint...@gmail.com:

> Just recently installed Qubes being new to Linux altogether I haven’t quiet developed my own best practices and the documentation online has a pretty steep learning curve. Anyway I was wondering what do you guys usually perform after a clean install. What do you do on a weekly basis, monthly, annually etc? How do you optimize Qube OS or is it already pretty optimized?
>

I set up a trim cron job per https://www.qubes-os.org/doc/disk-trim/ and
set issue_discards = 1 in /etc/lvm/lvm.conf. Thought I also set up
something to delete all logs older than a month but either I forgot to
or it doesn't seem to be working.

[Stuart Perkins]

Starting your Linux life with Qubes is a bit like starting your political career by running for President, or starting your mountain climbing hobby at Everest. Much of what you do with Qubes is no different than straight up Linux, but there is a lot more to it as well. If you have previous virtualization experience, it is a plus. VMWare is where I started back in VMWare Workstation 4 days. I was a paying customer of theirs from versions 4 through 6 before jumping over to VirtualBox. Qubes with its Xen based virtualization was a logical next step for me...as I was already planning on moving over to Xen.

What I do as a matter of course with my Qubes box is create ONE clone of each template...Fedora and Debian are the ones I use...and proceed on my merry way. I do the updates on the templates, and if there is a TON of updates...not just a browser like Chrome, Vivaldi, Chromium, Firefox...I back out of the update without doing it, delete the old clone of the template (space is a bit tight) and make a fresh clone of the working template. If the updated template causes trouble, I shut down everything but dom0, change all of the VM's using the borked template to use the last clone, delete the borked template, clone the clone back to the original name then change all the VM's to use the original name again. A small PITA but it pretty much guarantees that I am workable in the event of a borked update...which unfortunately does happen from time to time.

I use qvm-clone and qvm-ls and qvm-prefs on the command line in a dom0 terminal to make the changes, but they could be done through the gui interface.

I'm still on 3.2 with an install of 4 planned as soon as I get my new motherboard received and installed...my usb's are toast on this one.

Stuart

[22...@tutamail.com]

To answer the OP question you would use the clone for AppVMs, for example:

1) Original Fedora Template = I avoid using it
2) Clone of "Original Fedora Template" = Vault AppVM
3) Cloned Template with Libre Office installed = Personal VM & for another disposable VM for printing and opening email attachments (multiple disposable VMs available in 4.0)
4) Cloned Template configured for VPN = VPN AppVMs

If one screws up due to my doing, borked update, suspicion of malware I delete the clone and rebuild it from my Original Template. I highly recommend backing up your data VMs prior to updates (I can't stress this enough!). When I first started I screwed up a lot and was constantly reinstalling Qubes.

Similar cloning for Debian...I tend to use Debian where I can. The logic is the more software you install in a template the more vulnerable the template becomes...

I use the GUI but also picked up some commands for the terminal. I didn't know Linux but figured I would start with Qubes as I needed the security ASAP(I didn't have a choice).

Here are some basic commands I might use in a terminal:

Debian - To install Nautilus
su
apt-get install nautilus

Debian - To install OpenVPN
su
apt-get install openvpn

Debian - To install GNOME (Including Libre Office):
sudo tasksel
select GNOME (with space bar)

Fedora (Install Libre Office):
Sudo dnf install libreoffice

Update Dom0 in terminal:
sudo qubes-dom0-update

I again thank all on this mailing list who have helped me directly and indirectly. I also recommend to donate if you can to keep Qubes going...its good stuff! Kudos to the development team and all those writing code...thank you!

[22...@tutamail.com]

...always forget something right after hitting "Post":

Similar to Stuart to avoid a borked update which happens(although rarely these days) I:

1) Back up my data prior to an update
2) I only update my original templates after updating the clones, if the clones update OK I then update my original template

[brenda...@gmail.com]

My recommendations, incorporating some other previous recommendations.

0) After install, clone the baseline templates, then re-point all the non-standalone VMs to the clones. Update the clones regularly. This avoids the catch-22 of having your network broken on all your templates. If a clone breaks, you can easily remove it, reclone the baseline, and update the new clone to where you need it sans the breaking package(s).*
1) Backup your templates and Qubes.
2) Test restore your backups onto a new Qubes installation once after the first backup and at least twice a year. Certainly before repaving your primary machine with a new install.
3) Backup extremely important files (your source code, legal documents, etc.) to appropriate storage elsewhere. E.g. github/etc. for public source code, (secure) removable media or trusted secure online services (e.g. spideroak) for legal docs.
4) Keep a list of all modifications you have made to each template, any standalone VMs or to dom0 in your vault or in online storage: e.g. all rpms/debs added to baseline template, kernal version or option changes, pulled/built packages, configuration changes, etc. This will reduce your annoyance level when you decided to/are forced to rebuild the system from installation media and new templates and keep finding gaps when you are attempting to work.
5) Keep dom0 customizations to a minimum. There are no templates to save you.
6) Update dom0 sparingly, only after making backups, only as needed. There are no templates to save you.

* at some point we'll need to talk about how to keep the Qubes menu clean with all these clones around. :)

B

[Swâmi Petaramesh]

Le 04/03/2019 à 13:03, brenda...@gmail.com a écrit :
> * at some point we'll need to talk about how to keep the Qubes menu clean with all these clones around.

It would surely help much to have a « Include in menus » checkbox in the
VM properties, to avoid polluting the menu with clone VM entries, and
avoid starting by mistake an app from a clone backup VM...

ॐ

--
Swâmi Petaramesh <sw...@petaramesh.org> PGP 9076E32E

[brenda...@gmail.com]

On Monday, March 4, 2019 at 7:14:40 AM UTC-5, swami wrote:

> Le 04/03/2019 à 13:03, b...r@gmail.com a écrit :
> > * at some point we'll need to talk about how to keep the Qubes menu clean with all these clones around.
>
> It would surely help much to have a « Include in menus » checkbox in the
> VM properties, to avoid polluting the menu with clone VM entries, and
> avoid starting by mistake an app from a clone backup VM...

Perhaps...of course, that might make discovery difficult for new users as you would need to run a dom0 command to get to get to the screen to enable the checkmark if the checkbox was removed.

Maybe a toggle-style menu item or two at the top of the Q menu:
- Show (Hide) Template VMs
- Show (Hide) Non-included VMs (using your checkbox approach)

e.g. I would probably mark the baseline (salt-installed) VMs as hidden to make it less likely I update them by mistake

Alternate ideas to toy with:
All template VMs should be on a sub-menu.
All Salt-installed template VMs on a different sub-menu.
All Salt-installed templates volumes are immutable, and must be cloned for both updates and use with VMs. Note: LVM thin-provisioning avoids wasted space.

Brendan

[unman]

I remember when there was just such an option available, and a toggle at
the top of the Manager to show/hide . It was lost in the transition to
the Qube Manager.
Put in a feature request on github for this. No: there's already one
there:
https://github.com/QubesOs/qubes-issues/issues/4005

unman

[Chris Laprise]

On 3/4/19 7:03 AM, brenda...@gmail.com wrote:
> My recommendations, incorporating some other previous recommendations.
>
> 0) After install, clone the baseline templates, then re-point all the non-standalone VMs to the clones. Update the clones regularly. This avoids the catch-22 of having your network broken on all your templates. If a clone breaks, you can easily remove it, reclone the baseline, and update the new clone to where you need it sans the breaking package(s).*

I have not seen many (if any) cases of people ruining all their working
templates. So I would only follow this advice if I intended to use only
one template on my systems.

Otherwise, it may be better to simply use the Qubes-installed templates
normally, and make a temporary clone when experimenting.

The reasons are that most users have more than one template anyway,
Qubes can often revert template changes (i.e. remove the bad update),
keeping non-updated templates can be a security liability, updating the
extra templates is a burden, and they eventually eat disk space. Also,
if worse comes to worse somehow, then a template rpm can be taken from
the Qubes install media, etc. and that can be used to download a
_current_ version of your preferred template(s).

-

Its also worth noting that if you really want to keep template clones
around, there are a couple ways to do it that don't populate VM menus
and lists: One way is to snapshot the template -root volume, and another
is to simply backup the template VM.

> 4) Keep a list of all modifications you have made to each template, any standalone VMs or to dom0 in your vault or in online storage: e.g. all rpms/debs added to baseline template, kernal version or option changes, pulled/built packages, configuration changes, etc. This will reduce your annoyance level when you decided to/are forced to rebuild the system from installation media and new templates and keep finding gaps when you are attempting to work.

IMO this should be #1, because consistency matters a great deal esp.
when modifications have some impact on security. Re-doing customizations
based on memory is for the birds, and its not hard to remember to write
something down when changing a template or dom0.

> 6) Update dom0 sparingly, only after making backups, only as needed. There are no templates to save you.

You can also take this a step further and make a snapshot of the dom0
root volume before updating. With the default Qubes config this is a
quick process and means using 'lvcreate --snapshot' on the
qubes_dom0/root volume. For completeness, a copy of /boot and boot
sector should also be made just before the snapshot.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[awokd]

Chris Laprise wrote on 3/4/19 7:40 PM:

> You can also take this a step further and make a snapshot of the dom0
> root volume before updating. With the default Qubes config this is a
> quick process and means using 'lvcreate --snapshot' on the
> qubes_dom0/root volume. For completeness, a copy of /boot and boot
> sector should also be made just before the snapshot.

Good idea, thank you. This will help for kernel updates in particular.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/03/2019 6.03 AM, brenda...@gmail.com wrote:
> My recommendations, incorporating some other previous
> recommendations.
>

> [...]

>
> 1) Backup your templates and Qubes.

Strongly agree. The need for backups is not Qubes-specific, but it is
at least as important with Qubes as it is with computers in general.

> 2) Test restore your backups onto a new Qubes installation once
> after the first backup and at least twice a year. Certainly before
> repaving your primary machine with a new install.

Remember that there's also `qvm-backup-restore --verify-only`. I
recommend using this immediately after every backup you create.

> 3) Backup extremely important files (your source code, legal
> documents, etc.) to appropriate storage elsewhere. E.g.
> github/etc. for public source code, (secure) removable media or
> trusted secure online services (e.g. spideroak) for legal docs.

I suggest pairing this with qvm-backup. In other words, for confidential
data, use qvm-backup to create an encrypted (and optionally compressed)
authentication- and intengrity-protected backup before uploading it to
the cloud.

> 4) Keep a list of all modifications you have made to each
> template, any standalone VMs or to dom0 in your vault or in online
> storage: e.g. all rpms/debs added to baseline template, kernal
> version or option changes, pulled/built packages, configuration
> changes, etc. This will reduce your annoyance level when you
> decided to/are forced to rebuild the system from installation media
> and new templates and keep finding gaps when you are attempting to
> work.

Yes, keeping a list is highly recommended.

> 5) Keep dom0 customizations to a minimum. There are no templates
> to save you.

I'm not too worried about this, because my customizations are all
backuped up when I qvm-backup dom0.

> 6) Update dom0 sparingly, only after making backups, only as
> needed.

I have to caution against this. Delaying dom0 security updates "voids
the warranty" with respect to a lot of the security that Qubes offers. I
recommend installing security updates ASAP. (This is not the same as
recommending that everyone use the security-testing repo. I mean that
regardless of whether you choose to use security-testing, you install
available security updates as soon as they're available to you, but
always make a backup first.)

> There are no templates to save you.

That's what backups are for. :)

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlx9z40ACgkQ203TvDlQ
MDD12g//bWjBXS4/AxX10hVU3lBbp3Lb1Dux0GhmHWG13G/qkb20DHVID+oTAX3c
Hr4d1Yb/ZwbttLMOmGtkel3QPF2VgOZbSK6hks0qt4Ia4yj0EsyrS87mBgyeAxiW
eUtcuYhr572QTZfUUvYlzp9XeX/pZrO/DqqL/7HTvaB5UEafvRsG6A/ZYMCsCg/s
Ktj90zi3x8jVcTvjqbvNDSjnRUA1AY3YCXDO4opfqH4+DNGFnHKndrEhqvua1Ss7
Hsg+0IfoHWitZF0ajiEJ+XDFZDscSmb9/aONqQ6YZi9+kbt/udNNw7vEI/4YtU0E
Gvhmp9cr2hMkP+Wa9FBm05F4a76RJuj8+DUUvG8LRExxS7OETitUa0XJ97pN9qlT
IZcYDezjXHnlKk/Q8K/4leJtDQDfqYQlGYAO9HVlmAM/t7MQOda80bmJ346BmUnu
76gIHoTOptN9by88jBGLfhlZAhlnyETfpfau9YndkROUkKCMvQeAFSEwXPrFPijf
J0kjpXRf7cUTlMM/4q03+uTrgCbkZpyBvlDLZM0iwoyB4yQgSKGjZsT/uxnp5q86
1L9QCKBWtVo6SrTlU4R8BYVP880LpKeoliM/PQasxzxD3g3xuOdHpWllc4OHtdVn
dLoC3bEz8MH237Aj5Saj6QohUKpRYb4Zzx9h7XuWYPgpYNDDvY4=
=ZVe+
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 04/03/2019 1.40 PM, Chris Laprise wrote:
> [...] You can also take this a step further and make a snapshot of

> the dom0 root volume before updating. With the default Qubes config
> this is a quick process and means using 'lvcreate --snapshot' on
> the qubes_dom0/root volume. For completeness, a copy of /boot and
> boot sector should also be made just before the snapshot.
>

How would one use this snapshot to recover? Would you mind contributing
documentation about this so that those of us who aren't well-versed in
LVM can benefit?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlx9z54ACgkQ203TvDlQ
MDD0OxAAojuRtAdTDPAWIFxlH9dXLhx2L0ql22DZzybNlwOyW8LHhuhtaNuGi1aU
GKDh627WtIwxylb+rroIpkSjT5iP1yPdipuYC06dbVGG8UxAIEEjYa2G/HZ8t0Us
GVVXcZoRmmDtVdM10bHFogF/JOrZx8zJbb0vgL3avwHlH/rbWMmmxVw8yaMws+f3
7RUh1T53R2tGgGpL1PnspCE8Is6B1go4ah68kzZtvYbU9cL2mgq1R2U5rOxZf17h
ofM6jfaJpbT9rM0rwrDJXd6cx+Sa6bh/cH4UPFYVmMC4rQo5x/zyvsLDoyad3Jrk
L50pkK5fjCpmSV+TpNNK1BF8Glxlv22QmYg7HVMnY12viQNEGhnqw1ssOt9jCBCO
3XBq3b+EvIudEwVR6FkWq+tfZJfYiGnWRzXXt/fU25qFwsRwSPcJcSfNMgoXKh5S
x1OeAdZ03YWvecgJ8auLwTwJJKtT6M4ft6JfwpF3TRuZLszgyjFIKY3ZAUnGbyS1
X35goYzTQfCCULHFPGWydw7l6CUgdRCvgYhReopcHus5gTGNYTFz7VHQZpiDNadA
QPUFH/s2ZiRdCsmVHR0NkG9r/ntOMfg4gPAjPLWa+DR8CoTpye+7A959CSLeVYa3
uiPzgGrLuRs8ivQ6e5JlfXvBtvgGQogiVYUcZkiSdtJ3hNFxD3g=
=I7b9
-----END PGP SIGNATURE-----

[cooloutac]

Andrew do you have the link to the blog post JOanna made showing how she compartmentalize her daily life in Qubes. I was looking other day couldn't find it.

[cooloutac]

found it https://theinvisiblethings.blogspot.com/2011/03/partitioning-my-digital-life-into.html

[cooloutac]

. I only make clone template when I'm going to install extra software. In case it borks something or is shady. For example I have cloned template for disposable vm, where I install printer drivers. One for personal vm's that I installed libre office. One for sys-usb and sys-net.

Most my trusted vms use standard templates. I use both debian and fedora. one for less trusted trusted, one for more trusted trusted.

Having alot of templates is a real resource hog and a pain to update. I feel its more important to compartmentalize with appvms rather then get caught up in having multiple templates. Unless you are going to be installing alot of software or testing with them.

When I backup. I don't backup templates.

[cooloutac]

I also don't do anything in dom0. absolutely nothing.

and If I have to restore my system. The only thing I'm restoring is the appvms. I will manually reinstall Qubes and re clone two or three extra templates I need, and manually reinstall the software I need in them.

I have not used paranoid mode to restore appvms yet. But when the time comes I will be looking into it.

[airele...@tutanota.com]

Mar 4, 2019, 12:03 PM by brenda...@gmail.com:

My recommendations, incorporating some other previous recommendations.

0) After install, clone the baseline templates, then re-point all the non-standalone VMs to the clones. Update the clones regularly.

...

4) Keep a list of all modifications you have made to each template, any standalone VMs or to dom0 in your vault or in online storage: e.g. all rpms/debs added to baseline template, kernal version or option changes, pulled/built packages, configuration changes, etc. This will reduce your annoyance level when you decided to/are forced to rebuild the system from installation media and new templates and keep finding gaps when you are attempting to work.

For added packages in debian/whonix templates, if you are keeping the baseline template around, don't need to track them manually. Can just run `apt-mark showmanual` in the baseline and then the cloned template, then diff -u them to get a list of added packages.

[Chris Laprise]

On 3/4/19 8:23 PM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 04/03/2019 1.40 PM, Chris Laprise wrote:
>> [...] You can also take this a step further and make a snapshot of
>> the dom0 root volume before updating. With the default Qubes config
>> this is a quick process and means using 'lvcreate --snapshot' on
>> the qubes_dom0/root volume. For completeness, a copy of /boot and
>> boot sector should also be made just before the snapshot.
>>
>
> How would one use this snapshot to recover? Would you mind contributing
> documentation about this so that those of us who aren't well-versed in
> LVM can benefit?

I'll write it down quickly here first:

1. If you want to be extra careful, save a copy of /boot and boot sector
in the root volume:

$ sudo mount /boot # May say 'busy, already mounted'
$ sudo sh -c 'find /boot 2>/dev/null | cpio --quiet -c -o >/boot-bak.cpio'
$ sudo dd if=/dev/sda of=/bootsector-bak count=1

2. Create a snapshot of the dom0 root volume:

$ sudo lvremove qubes_dom0/root-snap1
$ sudo lvcreate -kn -ay --snapshot qubes_dom0/root -n root-snap1

3. Then run 'qubes-dom0-update' as you normally would.

-

In the event that the dom0 update results in a serious "unfixable"
problem with dom0, you can use your root snapshot to recover. You will
need to boot into a rescue shell first.

Once you get to a shell:

1. Run 'lvm'.

2. At the lvm prompt, type:

lvm> lvrename qubes_dom0/root root-bad
lvm> lvrename qubes_dom0/root-snap1 root

3. Reboot.

Restoring a snapshot of the root lv like this should resolve most snafus
resulting from dom0 updates. But if the system still won't boot and you
made a backup of /boot then you can un-cpio it to the boot filesystem.
(Its also possible that the uefi partition may have to be restored or
fixed, but I'll leave that for someone else to fill in.)

[one7...@gmail.com]

Hello,

regarding the topic how to clean up the Qubes Menu if you use lots of templates, maybe my "poor man's" show/hide-script can help.

I am using this to hide templates or AppVMs which I don't use very often or which I only use as base templates.
(All my AppVMs use custom build templates, which are based on a fedora/debian minimal template)

> Brendan:

> > Maybe a toggle-style menu item or two at the top of the Q menu:
> > - Show (Hide) Template VMs
> > - Show (Hide) Non-included VMs (using your checkbox approach)

Unman:

> I remember when there was just such an option available, and a toggle at
> the top of the Manager to show/hide . It was lost in the transition to
> the Qube Manager.
> Put in a feature request on github for this. No: there's already one
> there:
> https://github.com/QubesOs/qubes-issues/issues/4005

Usage:
qubes-app-menu hide <name-of-vm/template>
... this will move all menu files from the AppMenuFolder (~/.local/share/applications) to a "save location" and therefor the menu will not show those entries.
qubes-app-menu unhide <name-of-vm/template>
... will copy the files back and there for the entries will be shown in the qubes menu

If you launch the script without arguments it will show how it works, and if any entries have been hidden.
Feel free to improve, as you might guess, I am not very skilled in scripting ;-)
Attention: the script will not do any error checking, if you use an AppVM name, which doesn't exist.

--- 8< --- --- --- --- 8< --- --- ---
!/bin/bash
# name : qubes-app-menu
# purpose: Hiddes menus from the qubes menu for AppVMs
# Usage : qubes-app-menu hide|unhide <AppVM>
# Link : https://github.com/one7two99/my-qubes/blob/master/dom0/qubes-app-menu

cmd=$1
HiddenAppMenuFolder=~/hidden-dom0-applications
AppMenuFolder=~/.local/share/applications

#check if $2 is set
if [[ -n "$2" ]]; then
AppVM=$2
else
cmd=0
fi
case "$cmd" in
'hide')
mkdir -p $HiddenAppMenuFolder/$AppVM
mv $AppMenuFolder/$AppVM-* $HiddenAppMenuFolder/$AppVM
echo "Apps for $2 hidden from Qubes Menu" && echo
#notify-send --urgency low --icon image --expire-time=5000 "$0" "Apps for $2 hidden from Qubes Menu"
;;

'unhide')
mv $HiddenAppMenuFolder/$AppVM/* $AppMenuFolder
rmdir $HiddenAppMenuFolder/$AppVM/
echo "Apps for $2 viewable in Qubes Menu" && echo
#notify-send --urgency low --icon image --expire-time=5000 "$0" "Apps for $2 viewable in Qubes Menu"
;;

*)
echo
echo "Usage: qubes-app-menu hide|unhide <APPVM>"
echo
echo " hide <APPVM> : Hide the app menu entries for an AppVM"
echo " unhide <APPVM> : Show the app menu entries for an AppVM"
echo
echo "Currently hidden AppMenus:"
cd $HiddenAppMenuFolder && ls -1
echo
;;
esac