How do you use Qubes Policies?

fsflover · May 30, 2021, 11:56am

I think this is not straightforward. Let’s say, I receive a couple of emails/intant-messages with links in some qube. I click on them and they are opened each in its own dispVM.

Do I want this or do I want them to be opened both in a single dispVM? It probably depends on how much I trust the senders and the linked websites. I don’t think I will ever want to apply “opening in the same dispVM” by default unless (1) I have not enough RAM or unless (2) opening a dispVM is annoyingly long. In the (1) case, such option would probably be useful. I expect that it could be shown in Advanced qube Settings, probably with a hint that it may decrease your security/privacy but save RAM. In the (2) case, I would very much prefer that the following issues are solved instead:

github.com/QubesOS/qubes-issues

Proposal and code for instantaneously started disposable VMs

opened 09:02AM - 13 Dec 15 UTC

qubesuser

C: core P: major S: in progress T: enhancement community-dev release notes

**Community Dev:** @qubesuser ----- Starting disposable VMs is faster than… normal VMs, but it can often still take several seconds and be a noticeable delay in the user experience. This proposes to solve this issue by keeping one or more disposable VMs always around runnning, but without qubes-guid started and thus "invisible". When the user requests a disposable VMs, the system takes one of those cached disposable VMs, adjusts them if necessary and starts qubes-guid, and then starts another cached disposable VMs for the next request. This allows instantaneously started DispVMs at the cost of losing 1.5-6 GB of RAM, which can be a good tradeoff at least for machines with >= 16GB RAM. There are two ways of doing this: the most flexible way would be to support any DispVM usage by starting the appropriate service on the cached DVM, and there is an inflexible but faster way that pre-starts the application as well, but only supports a limited number of DispVM applications started from dom0 (typically a web browser and a terminal). My code implements the "inflexible" way and offers two modes: a faster "separate" mode that keeps around a DispVM for each configured application, and a slower but less RAM hungry "unified" mode that keeps a DispVM with all the applications running, and kills the ones not needed at user request. You can find the implementation at: https://github.com/qubesuser/qubes-core-admin/tree/insta_dvm You'll need to create a configuration file in /etc/qubes/dvms like the one provided in the branch. The mode is chosen automatically depending on available RAM, but can be configured in /etc/qubes/cached-dvm-mode The branch is missing packaging for qubes-start-cached-dvm and the dvms config file, systemd integration for starting it at boot, and making dom0 start menu entries use it. It's also somewhat hackish overall and might need a rewrite in Python and adjustment to the new core code if shipped after that.

github.com/QubesOS/qubes-issues

Preloaded DisposableVMs

opened 08:28PM - 13 May 20 UTC

ejose19

C: core P: default T: enhancement

**The problem you're addressing (if any)** Disposable vms are very useful for t…he intent they're made, however one drawback they have is that usage is not instant as other appvms, and one need to wait for it to load before using it (varying from 7-20s depending on hardware) **Describe the solution you'd like** It would be great if there was an option to "preload" the dispvm (quantity to preload would be defined by the user and limited by hardware specs) so whenever you need to use a dispvm the target program launches automatically. **Where is the value to a user, and who might that user be?** It would be a great benefit in terms of speed and convenience depending on how much the user relies on dispvms **Additional context** Currently behaviour would be preserved, if you launch a program for a dispvm using the qubes menu, each call would use a different preloaded dispvm, no reuse would be made. Also when one dispvm is "used", another one would be preloaded to keep the defined amount always ready.

Note, that I can always simply use ctrl+c, ctrl+shift+c, ctrl+shift+v, ctrl+v instead and open the second link in the first dispVM in this way. Anything more complicated/flexible than that might be useless.