What's the future of QubesOS Default Security Configuration?

It’s you who shaped my thinking more than any other community member. The pupil following the ideas of the teacher shouldn’t surprise anyone.

I haven’t looked into split-browsers either and are afraid I have little to add and are bound to repeat myself. I can and have made arguments for and against all kinds of browsers, but in summary I would boil it down to:

  • disposable for everything that doesn’t need state/login
  • compartmentalize as much as possible / useable
  • disable / limit scripting as much as possible

I use Brave mainly for performance reasons, but it has the added advantage that limiting scripts, tracking and fingerprinting are core features and do not require additional plugins. They’ve also made it very easy to set the defaults and adjust them on a per site basis so it doesn’t feel like a chore or gets annoying.

There are no scripts or salt to set this up. After generating my templates I simply create my online-dvm, launch it and make my most restrictive default settings in the profile without ever visiting any website. This becomes my template for disposables and I also clone from it for the more specialized qubes that will hold state. When I visit such a site for the first time I then use the shield icon to allow scripts for that specific site and maybe non-third party cookies.

I imagine one could automate the creation of the the qubes and placing the restrictive default settings / profile.

1 Like

Thank you for this, I am looking forward. All your Salt stuff is awesome, it helps a lot.

Absolutely agree again. When I use single tab instance browser dispVM to access my online banking, what is there to be hardened?

When I use single tab instance browser dispVM to access porn site, what is to be hardened there and it’s not at least side channel attack defense?

Accessing online banking and porn site in the same browser dispVM isn’t Qubes anymore and most likely no hardening can help me not being stupid …

1 Like

Well, it IS Qubes, but it’s also misuse or at the very least being unclear on the concept, almost as bad as surfing the internet in dom0. :smiley:

1 Like

I was hoping that someone might have some thoughts on template


I have thoughts, but are unsure how useful they are:

  • There was a time when I used Kicksecure templates converted from debian-minimal. I wasn’t really able to tell what it was doing to harden beyond the descriptions on its website. What I did notice was a marked increase in memory usage and things being a bit slower. My understanding is that the later might have been an effect of AppArmor?

  • The problem (I think) I see is that any kind of hardening will require configuration (like a whitelist, checksum database, etc.) and therefore require a level of understanding and maintenance that might exceed both the willingness and capability of most users.

The later was at least where I failed: it appeared to me that to have any meaningful gains in hardening I would have to invest a lot of time learning and maintaining and reached the point where I wasn’t at all sure it would be worth the trouble (in the context of Qubes OS only obviously).

Maybe this at least get’s the ball rolling in terms of a discussion / proposals. I’d be happy to change my mind when confronted with new information.


Both the Kicksecure Hardened Malloc and Kernel Runtime Guard seem interesting, but they both have the disclaimer “for testers only”.

1 Like

Most of my templates are KS-based with both HM and LKRG enabled (and a bunch of extra hardening features listed in the various KS docs). Besides a slightly longer startup time I haven’t ran into major issues.


What kernel are you using?

I just tried to install LKRG, and the DKMS installs for 5.10 but fails for 6.1.

5.10 but I was planning on trying bookworm’s 6.1 with some free time.

Yesterday I tried installing the malloc and kernel guard, they don’t need any extra time investment, you just install them and they do their thing.

It’s difficult to gauge how effective they are and if you get any meaningful gains, I couldn’t find any information on which in the wild exploits had been mitigated by either of them.

I also noticed an increase in memory used, my browser qube with brave increased from 850 MB to 1.2 GB under similar loads. The kernal guard also has a negative impact on CPU usage, around 2.5-5% in everyday use, but it should be a lot worse in high IO loads, like compiling source code.

I have switched my browser qubes to kicksecure, I have enough memory that trading some resources for extra potential security is worth it for me.

1 Like

Can you please share how you do the following:

  1. How do you view/edit each and every file in a disposable all the time, obviously the view/edit is part of your process workflow, so isn’t it a burden?
  2. Why do you have multiple offline storage qubes and how do one setup it and, if it’s offline, why not edit/view within it?

Did you generate the above tests using this tool?

Where do I need to install it, within the template?

Yes it is a burden, it’s the price I pay for peace of mind. :wink: Also I’ve created a little workaround for DispVM startup time but beware (!!!) if used in a wrong way it will negate the advantages of edit/view in a DispVM.

The idea is to move the time penalty to the end of the session (shutdown, restart) instead of the beginning (e.g. have a DispVM pre-loaded). However if you then go an edit multiple files in the same session or forget to shutdown/restart you’ve shot yourself in the foot and the entire advantage of using DispVM’s is out the window. SO PROCEED WITH CAUTION and be sure you understand what you are doing!

I don’t, but one could to keep data compartmentalized. It’s a trade off between compartmentalization and ease of backup.

Since I follow the ‘never edit/view in storage qube’ rule strictly, I allow myself the exception of having it all be in the vault qube.

Nothing special at all here. Just make sure it doesn’t have a NetVM set and optionally base it on a minimal template to prevent yourself from accidentally viewing/editing anything in it. You’d probably want to install some packages in that template like a file manager, but that’s another topic. Make sure to consult the documentation should you choose to go down this route.

If you’d open an infected file (e.g. an office document with a macro exploit) it could potentially spread to other files stored in the same qube. I am assuming that files might be malicious no matter where they came from. As long as I only edit/view them in an offline disposable nothing really bad could happen – right? The malicious code executes in the dispVM, has only access to the file it came from and “dies” once the disposable closes.

1 Like

Thought of a funny meme today related to this thread…

Problem: You have a popsicle that is melting on a hot day, and you want it to stay frozen.

RegularOS solution: Put it in a freezer

QubesOS solution: Cut the popsicle into 10 pieces and place each piece on a separate hot sidewalk