ccess to your disk decryption keys, your bare-metal hardware firmware, and can patch your Xen hypervisor in memory.
disk encryption keys: true
firmware attack vector: true
patch xen hypervisor: also true
you can no longer trust the integrity of the backup files
kuhbs admin vm would control all other vms (it creates the usb vm, and also manages backups / restores, and hence has root@ all VMs), so thats true even with kuhbs-admin.
can silently inject backdoors into your backup templates or alter the kuhbs create-all script definitions
so can a compromised kuhbs-admin
it cannot manipulate the core Xen/dom0 isolation logging that proves a breach occurred
hm well i think qrexec stuff is logged in dom0, but I’m not sure, anyways, if we have kuhbs-admin, it could not mess with journal in dom0, correct
then a management Qube does look like a lot of extra engineering for very little operational return.
That being said, I am massively with you on the firmware side of things. I don’t much like that either.
how an attacker behaves before you even notice you need to reinstall.
you will not notice, which is one of the reasons I build kuhbs in the first place - to completely automate the installation and setup of Qubes OS, so I can do it in the morning while drinking coffee - each day. Including reinstalling Qubes and before that flashing the firmware.
Automating that will be fun, but its possible. Mostly automating at least, the Qubes install path you can fully automate, the crappy firmware tool not ofc x)
My approach to security has been shifting for a while from “build secure software / systems to trust things” to “destroy things and setup from scratch” bcs AI gives attackers fancy capabilities, but developers too, so you can kinda always assume your system is compromised, and its best to destroy everything and start from scratch every day (fresh install) because the CVE the attacker used might have been patched.
I’d also recommend recycling hardware regularly, understanding that this is a cost factor, which I cant write py for to help you with 
Your argument assumes you will know the kuhbs-admin VM is infected
I always assume everything is infected, which is why I wrote kuhbs, because start from scratch is the only way to cope with this when I receive an email once a day with 300 new CVEs found in fucking thunderbird alone.
They want to sit quietly, log your keystrokes, steal your crypto keys, or alter your git commits.
+1
You retain an un-fakeable “source of truth.”
I actually do not know WHAT is logged in dom0 (menaing I / me personally never bothered to look at the systemd journal in dom0). If it logs when qrexec calls happened, I highly doubt you (or me) will be able to say “ah! that means an attack!” - but it is possible to derive this from this data, yes.
If they get into dom0 via kuhbs, your hardware itself is now potentially burnt. A simple OS wipe and reinstall from a USB stick might not save you if they persistently backdoored your motherboard’s SPI flash.
If they are hardcore enough to mess with firmware (I think!!!) they are most likely state level actors, against which only anonymity will protect you, because No Such Agency has 0days for xen / qubes.
But I am with you on your argument none the less, yes.
If a management Qube handles this, you don’t actually have to give it “all of dom0.” You can use rigid qrexec policies. For example, instead of letting kuhbs run arbitrary bash scripts in dom0, dom0 only listens for very specific, tightly-parsed requests (e.g., “Only allow this VM to execute qvm-pci attach with these specific allowed IDs”).
Its hard (impossible) to know what kind of things one might want / need in hooks. Luckily hooks are just stupid bash scripts, and if you write something fishy in there, your AI audit will detect that 100%.
A kuhb definition is so utterly stupidly simple that you can audit that yourself without AI. It is much simpler than reading / understanding salt or ansible in fact. Its yaml and a bit of bash, in most cases.
But I do see your point. However it is extremely easy to audit (by design), and that is a valid counterpoint imho.
You’re still not wrong, I’m not dismissing your argument.
If kuhbs is a highly personal tool built by you, for you, and you strictly audit what goes into it—running it in dom0 with a clean, lightweight CLI is completely reasonable. The added complexity of a management Qube might feel like over-engineering.
Hm yeah well keep in mind that salt runs in dom0 and thats provided by the Qubes people, who encourage you to use salt 
Which means you’re somewhat encouraged to use the salt from other people, because nobody who doesn’t like MASSIVE pain is messing with qubes salt (trust me I tried lol).
So not fully with you on that one
But if kuhbs is meant to be distributed to other end-users who will blindly copy-paste third-party templates and repos, pushing it out of dom0 isn’t about making reinstallation easier. It’s about preventing a rogue script from gaining permanent, undetectable hardware persistence.
True, but for endusers the smallest problem will then be that the attacker has the ability to flash the firmware, because the attacker will most likely not need that capability - they will only need to make friends with that person and send them an email with “check out my fancy kuhb definitions” and then they own all the VMs (excluding dom0) - which as you noted, the enduser wont notice.
How do you plan to handle third-party definition safety if you keep it in dom0? Would you rely entirely on that AI-scanning pre-flight check, or are you thinking about implementing a strict internal sandboxing/parsing mechanism within kuhbs itself?
A kuhb definition lives from bash scripts, so you can simply implement stuff like this: Signal >> Download Signal for Linux
There is no way in code for me (that is sane) to validate “is this bash code malicious” - that can only be done by AI.
So I do see your arguments with state level actor capabilities and them permanently compromising the machine via firmware. However state level actors don’t need kuhbs for that, they get into your box with regular Qubes OS as well (I think). Or they just break in when you’re not at home to own your box. Not that hard really.
I still don’t fully see the reason for the extra code. However I also have said that I would love to have this - dont get me wrong here. I f-ing LOVE (!!!) the whole puzzle game around Qubes OS. I kinda do this because it soooo much fun to me, its like MASSIVE OCD addiction to make Qubes more secure and what not.
I still dont fully see the reason here. The arguments I took from your arguments that make sense to me are:
- firmware
- disk encryption keys
- well, you know, root@dom0. god mode.
compared to pretty much god mode (root@kuhbs-admin) - zero difference to an enduser, all of the endusers data is owned / can be manipulated, they wont notice anyways.
As said, kuhbs is still in development, and I will 100% research how much effort it is to run this all in kuhbs-admin. But just from the risk factors, I’m not super convinced its worth it. If its a ton of efforts and has lots of drawbacks.. Idk. Maybe its simpler than I think.
I need to setup some qrexec policies with qubes, and I need the ability to mess with i3wm. From what I know that kinda requires dom0, or at least sending data into dom0, which I could verify somehow but meh. Then there is a bug in there…
Gimme some time to check this out If its reasonably feasable, I’ll do it just for loving to do it I mean I want kuhbs-admin too, but not at to high a cost, because at the end its about the data (root@all-the-vms) and not defending against state level / high persistence threats with LOTS of cash for 0days. That war is lost in my opinion. I really dont think qubes gives even the slightest bit of protection against No Such Agency (only anonymity does, imho).
Kuhbs, even running in dom0, would still be vastly more secure than anything else available for endusers at this point. So to endusers, even kuhbs in dom0 is still a MASSIVE security upgrade compared to, say, OSX or ubuntu or so.
Kuhbs is (kinda) not really targeted at the ultra pro hacker using Qubes - I know they will find stuff they don’t like one way or another.
I mean the bloody thing has a gui for christ sake xD That would make even me raise an eyebrow (has a cool CLI too though, you are not at all forced to use the gui :P)
