I recently moved from whonix 17 to 18 in qubes and am adjusting to the new user sysmaint split. I’d like to use the split and not deactivate it. When I need to use sudo (for user, not sysmaint) should I :
- restart the appVM with boot mode set to UNRESTRICTED. Then do my sudo command. Then shutdown and revert to default user mode
Or
- run (in dom0) qvm-run -u root appVMname xterm
Do the sudo command in that terminal and then close xterm (and the dom0 terminal)
I’d like to know which option weakens the security of the split system the LEAST
I would assume that the second option is more secure because it only open a single terminal window with root and then is closed versus the boot mode in UNRESTRICTED opening the whole appVM up to the previous user privileges setup in 17 with all user applications and processes being impacted (vs just one xterm window)
Unrestricted Admin Mode completely uninstalls user-sysmaint-split. When selecting unrestricted admin mode as a Qubes App Qubes boot, that’s temporary as per Qubes Persistence, but in any case, not preferable.
Any theoretical malware that gained a foothold in account user could then modify files in the private image such as in /usr/local and /rw such as /rw/config/rc.local when user-sysmaint-split isn’t installed.
Therefore qvm-console-dispvm is clearly the winner here.
As a sidenote, there’s a third option that would possibly be more secure than either option already discussed; shut down the AppVM, set it to PERSISTENT Mode - SYSMAINT Session (this is available in AppVMs, not just in TemplateVMs), then start it and do what you need in the sysmaint acciont. That makes it harder for malware with a foothold in the user account to gain persistence as root, and avoids running a root terminal on an X server a potentially compromised user account has access to. (The latter is good to avoid since malware running as user could run arbitrary commands as root while the terminal is open by leveraging XTEST to emulate input and inject it into the root terminal.)
Thank you. My understanding was that this mode has reduced sudo functionality for user. Or is there a way to mitigate this ?
For example, if I want to sudo install a binary to /usr/local/bin and the binary is in /home/user/Downloads then I would need to move that to sysmaint so I could run the command. And whonix documentation indicates sysmaint shouldnt be used like that. For this, I seem to need the previously mentioned approach
Another use would be sudo mount and sudo cryptsetup open. Do you have any suggestions on how best to do those so a USB drive is available and mounted in user ? I have been using qvm-run -u root to run the mount and cryptsetup commands in xterm and then closing xterm. But I imagine these processes are still running as root so perhaps a security risk. I’d definitely like to be able to cli mount USB drives in user in whonix ws appVMs
Edit:
After some research it seems that using udisksctl mount instead of sudo mount would allow mounting the USB drive without needing to use sudo. Does that seem a secure substitution ?
Can you download the binary using the sysmaint account? Alternatively, can you verify the authenticity of the binary using a PGP signature or similar before copying it in? (Using the root account to copy a binary from user’s home folder into /usr/local/bin/ is as dangerous as booting into the sysmaint account first, but verification of the binary reduces the risk since that will prevent malware running as account user from tampering with the binary.)
You can run commands as root in the VM from within dom0 without needing xterm. qvm-run -u root vmname cryptsetup ...; qvm-run -u root vmname mount ... should work.
I’m not sure if it will work, but if it works, it should be fine assuming you trust the filesystems you’re mounting to not be malicious themselves.