I just looked at the Audio qube thread and it got me thinking… I feel like not having audio in dom0 makes a lot of sense.
I’m working on “kuhbs”, which very briefly described is a config management system + gui for endusers where they can click “install browser”, “install signal-desktop”, bla. A way for them to not have to understand pretty much anything of Qubes but still get the most out of its security.
I will ship this with my custom network chain which I consider to be reasonably secure. Very shortly:
all debian-13-minimal based, might switch to kicksecure
named disp nic vm with network manager (cause its easy)
named disp gateway vm with wireguard, dnscrypt-proxy, apt-cacher-ng and time sync
appvm firewall VM with Qubes-Snitch (appvm because you need to store saved rules)
named disp (optional) whonix gateway
“normal” VMs here or attached to firewall VM
Qubes has a ton of gimmicks and security bells and whistles you can switch on and off, and I thought I’d ask the community what you think makes MOST sense here.
sys-audio is a great example for this.
I was kinda thinking an admin VM maybe. Right now kuhbs runs in dom0…
I know of split ssh, split funky authentication 2FA sticks and alike. I also have to admin I haven’t used Qubes in a year or two, so maybe there are new funky things I missed.
If you were building a Qubes OS Laptop “for your dad”, or for an end user, what security things would you like included? Other than networking paranoia, this one I already covered reasonably well I think - but if you have an idea that you think is super important to have I’m all ears for network stuff too.
So long story short - what is your “security secret / favorite” that you always setup in Qubes that you think would make sense to have by default for end users who wont be able to open a terminal to write more than curl | bash ?
And something I haven’t done myself yet:
You know how you can set a default kernel? I’d love to have a second stream, a second default option, where you can set an hardened kernel instead - automatically created. So likely this:
Keep in mind that your common lawyer, human rights activist or whatever else in that category that used windows or OSX before doesn’t know much about linux / qubes.
Any default I set is basically forcing them to use it. Some people may find tor a bit shady, or don’t want their ISP to see them using tor. I will ship whonix gateway and workstation, but they can then use it or not.
So updates over tor is to hardcore for this. Not that I don’t like it, but I don’t think I should force everyone to do that (its easy to do with a bit of help from chatgpt or the forum, as in kuhbs can ofc do that (its still just a switch, the same it is in Qubes rn) but it can not be the default).
I actually love this, but I just disabled sudo completely (as in it exists, bcs it exists in debian-13-minimal, but there is no password / its unusable). However you can just press windows + alt + shift + ENTER on any window and get a root shell
Any enduser who will want a root shell can learn that keybind imho
If it were for me the whole setup would be OpenBSD templates, but those don’t support qvm-bla and alike, and I need an icon to show up in the tray for the wifi + password. So that I can’t do.
Remember: endusers need to be able to just use it intuitively.
Thats nifty, but not enduser. They can use whonix / tor.
kernel stuff
I’m leaving kernel stuff to the Qubes team, because I don’t want to do support for that Absolute stability is super important (which is why I’m also hesitant on that audio Qube).
Endusers also don’t know what a kernel is
hardening
I will try switching all my debian-13-minimal’s to kicksecure soon. If that works nicely, I might go with this.
But this is a per-kuhb thing, so if for example alpine (didnt try it yet) fully supports all the Qubes bells and whistles (qvm-bla) you can just roll your own kuhb and publish a repo on github for your custom kuhb’s with stuff like “my fancy app in an alpine template”.
It doesnt work for OpenBSD, which is SO UTTERLY SAD!!! because it doesnt support qvm-copy, qvm-run and alike, which is what kuhbs makes heavy use of to get things done.
Ah I should have added: What should be ENABLED by default. For example i2p network kuhb - no problem, thats easy to build, but its not something that I would give to an enduser to be enabled by default.
The user can click this kuhb and create it, thats no issue at all, but I’m looking for stuff that are done by the base installation of kuhbs.
If you want to pre-install things, my answer is nothing. Default Qubes OS is a reasonable starting point, most if not all of the gimmicks are situational, and should be opt-in.
If you just want to make more… Erm, plays? States? Whatever is the name for a written kuhb definition. I think you should do more network. I haven’t checked what you have apart from the things you mention here, and what you mention here is very limited. You only have one tunneling option with wireguard, and IMO wireguard is the worst one.
I can provide! pretty much anything (or literally anything), the question is what I should “force” the users to have by default. The user can install whatever they want (or just build a custom kuhb if they know a tiny bit of linux).
So its not about “what can it do” but about “what does it do by default”. The network chain above would be the default - or is at the moment.
So my question is if you would setup a laptop with Qubes for like 1000 people who don’t know any linux, what would you enable / setup on this laptop?
Think lawyers, human rights activists, bla.
Nothing by default, opt-in features upon installation. Even if we restrict the discussion to only network and only lawyers and human rights activists their setup might be very different. For example activists might be interested in heavy privacy measures and punching through restrictive networks, meanwhile lawyers probably value ease of use, reasonably fast connection, and secure document handling and storage more than privacy.
Its great as a performant and simple to use tool, but the combination of being udp-only and easy to detect make it very weak as a tunnel by itself. Correct me if I’m wrong, but even good old openvpn is more versatile, and other stuff like tor, i2p, yggdrasil, vless, shadowsocks, IPFS, etc. completely blow it out of the water.
