I am just wondering, wouldn’t it be better to remove sudo altogether and
A)add a qvm-connect tcp 22:sys-root: and allow only sys-root access to that port in /etc/qubes/policy.d
B)Bound ssh to localhost in every template
C)Create an ssh key for every template and transfer it to sys-root
D)setup remapping so localhost: leads to to ie sys-firewall or whatever
E)Create a script that loads up an alpine podman container everytime you run ssh and ssh to your desired vm like root@sys-net
I can only see 2 problems with this method
A)An attacker with both vulnerabilities to containers and ssh can access your whole system by opening a reverse shell afaik, even the templates if you configure this wrong, maybe a second sys-template-root would be better for that case
B)Having an appvm and dispvm conflicts since if both are online they techincally bound to the same port, and so remapping wouldnt work correctly
Now A is not really a problem becuase having attacks to both ssh and containers would take a state-level attacker, which qubes does not protect against, on the contrary this whole method would protect you from mid-level hackers escalating attacks
And B, well there has to be a better way to do this whole thing, I just came up with the idea and wondered if anyone has done such a thing, in which case link me to the git please?
I wonder if whenever a qube comes online we can setup a script that runs as root, generates a new rsa-key and sends it to sys-root, maybe a Qubes-RPC magician can enlighten me
Dont get me wrong this (probably) could never be applied to vanilla qubes as part of the default way users operate their computers, I am thinking of this as a more advanced user setup but afaik ssh-reverse shell attacks are few in the wild and container while more common it is still the most realistic choice we have unless you wanna try out a freebsd domU, in which case the UX must be afoul for such a task
Edit: if there is a Qubes-RPC magician reading this and you can achieve such a task I think the whole cross-qube contamination can be solved completely in systems with high ram, if we can keep ssh-keys in a separate vm or in dom0 then we can spin-up disposable vms in a second in systems where you have enough ram to preload 2-3 of them, I could envision adding an option in my dmenu to run a disposable-root for sys-firewall and a window poping up already logged in via ssh to sys-firewall, but these are only nightmares for my 16gb ram unless I get around setting up an alpine template and locking the disposables at 256mb ram