tasket
commented
6 years ago @najamelan - Thanks for the feedback. However I should point out that the 'vmsudo' configuration doesn't prompt for passwords. Instead it behaves much like the Windows UAC prompts in this respect, only it uses Qubes RPC for the Yes/No input so it is more secure. In the course of customizing and troubleshooting Qubes installs, it hasn't caused me any frustration... the prompt appears in dom0, I wait 2 seconds, then I hit Enter.
As for identifying programs and resources within VMs, this would probably have to be handled by the VM itself for architectural reasons I won't elaborate here. But vmsudo is necessarily integrated with dom0 so this level of granularity is not a good fit for Qubes' trust model.
FYI, its likely you'll encounter templates like fedora-26-minimal on Qubes R4.0 at some point. IIRC these don't have the usual 'instant auth' config, nor the vmsudo config. They're basically locked-down so the only way to get root is by qvm-run -u root from dom0, which is interesting and also satisfies the prerequisite for this project. There's no reason I'm aware of why users couldn't keep all their Linux templates configured this way.
najamelan
I agree that defense in depth principle is not respected by the default qubes vm policy. I also completely disagree with Joanna Rutkowska's arguments on this point.
Nevertheless in the week since I have started installing Qubes, I haven't looked into re-enabling sudo authentication. Why? Because I'm busy full-time trying to debug and work around all the bugs and inconveniences in Qubes. After a week I still can't use usb storage, the screen locks randomly during use, I can't suspend or hibernate, and my system won't shut down unless I hold the power button. Oops. There is only so much inconvenience that is tolerable before giving up on a "secure" system. Secure is between quotes, because why assume that people who can't write usable software can write secure software?
Sudo authentication adds another layer of inconvenience having to type a password every x minutes. So I would like to suggest an alternative approach, that btw can be applied to all linux distros.
Security without having to type a password. Windows does this by presenting the user with a dialog box that can only be clicked by a real physical input device. That's an improvement. Since qubes is already instrumenting VM's and communicating to the dom0, it would be possible to present the user with such a dialog...
... BUT both sudo and the windows approach suffer from another problem though. They say give me full control over your system or you can't use my software! End of the discussion. Personally, every time that happens, I think, well, I really don't see why a game needs Administrator Privileges, but hey, I would really like to play this, and anyways, they all ask for privileges... let's make a little prayer for security before enjoying the game.
Ideally on a desktop computer, when something needs elevated privileges, I should be able to see something like: Program X wants write privileges on file Y. (Program X provides following explanation about the necessity of this: xxx) Allow? Yes|No.
That way, the user has control over who get's to do what, but does not need a password. Even better might be to have a clear overview when installing the program so you don't need to have that dialog every time, or a checkbox don't ask again. Or even better don't interrupt the users workflow with dialog boxes, but I have no good solution for this problem.