Continuing the discussion from [Question] Strange dependencies update:
I would worry more about this instead:
Continuing the discussion from [Question] Strange dependencies update:
I would worry more about this instead:
What’s to worry about?
Any one who has accepted the arguments for passwordless root has always
expected this sort of escalation, although as it is a local exploit it’s
somewhat less bothersome.
I don’t know what the anti-passwordless-root people will say.
In principle, one could use ReactOS or BSD as Qubes VMs, then such VMs would not be vulnerable to this – this is what a good compartmentalization is.
I just popped a root shell in my fully updated whonix-ws-16 and fedora-34. Fortunately Qubes’ compartmentalization stops this from compromising further qubes .
For reference, the passwordless sudo @unman is talking about is documented here:
I prefer defense in depth. I’m not saying that Qubes should make passwords default for sudo, just for myself I cannot always efficiently/reasonably split each app instance into an individual VM.
For defense in depth, I would prefer that programs have some kind of namespace separation in the particular VM and not just give effective root to everything. That way exploits/trojans have to actually pull some legwork to exploit a VM
Just my preference
You may use firejail, but I’ve not tested it on Qubes.
And for services you could use firecracker.
Also, Alpine VMs can be made very small and lightweight.
I want dom0 on BSD ^^ A shame Xen does not work on openBSD (afaik).
Defense in depth is also another valid strategy. And they can be complementary. Nothing prevents you from “Replacing passwordless root access with Dom0 user prompt”.
But as you can see, in the original post defense in depth, particularly done by the kernel is not enough. And for good reasons, Qubes gets rid of sudo passwords.
Actually, regarding that:
Good to know. moved the discussion into its own topic: