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.
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.
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.
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.
Yes it is a burden, it’s the price I pay for peace of mind. 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.
Also I’ve created a little 