I’ve seen a recent uptick in requests for more security in domUs (templates, mainly), but most if not all have been vague and uninformed. I’d like this, but the first step in asking them to work on this is to present clear, concrete goals.
If you want more template security, then give your reasons here.
This would be better discussed on GitHub 
This is more likely to end up into something real.
What do you mean by “on Github”? Because…
Where’s the best place to discuss Qubes?
That would be the Qubes Forum and the qubes-users mailing list. Please have a look at our discussion guidelines before diving in. Enjoy!
Since I don’t see anything else that could be additionally protected against of that’s not already included in the stock minimals and Qubes as general, and I can’t imagine anything else beside compartmentalizing as much as possible the templates for the purposes m threat model is defined of, Iam all eager to hear what I’m missing.
I made this to give voice to people who do want more security, with some direction to help them express their wishes in a more productive way. The idea would be to link to this when people ask for more security vaguely, so that if they have a thoughtful concern, we can see more clearly, kind of like Solene’s backup ideas post.
I’d like to keep all the replies here on topic, that is to say responses from people who want more security in the form of specifically what they want to protect and what these protections would do that Qubes doesn’t already. They don’t have to be technically inclined, it can simply be “I want to protect this, and I think a more secure template would do that in a way Qubes can’t.” This has the benefit of both allowing those who have real concerns to get attention (by providing direction on how they can present valid concerns) and by educating those who don’t realize Qubes protects them already, whether naturally, or by using the features in a new or different way. As for me, for instance, I believe that a lot of this is just people who aren’t “thinking with Qubes,” and I think there’s a reason that’s the Qubes tagline: if you want to use Qubes, you have to think with Qubes. You need to rely on proper trust boundaries and segregation of sensitive data from unsafe actions and code.
That being said, I also think that that is an ideal and not reality. Qubes’ virtualization has been made, purposefully IMO (not maliciously), into a single point of failure. By not including general security features, they have made attacks against individual qubes, and then potentially the hypervisor, low-cost. Now, successful exploitation of Xen is certainly high-cost, but I don’t like the idea of making individual qubes soft targets. My problem isn’t so much that Qubes doesn’t put active effort into guest security, but that they tout the hypervisor as some unbreakable piece of code in their active sabotage of guest security under the guise that full security isn’t realistic and that Qubes protects. The problem there is, again IMO, pure hubris. The hypervisor is very hard to attack successfully, but why do we insist on betting the farm on it? The fact is, we’ve seen several XSAs apply to Qubes hypothetically, and we don’t know if they were exploited in the wild. Can we not admit that real guest Linux security isn’t realistic right now, but that it is a good goal to work towards and to take what’s there? Secondly, while everything can ideally be solved by “thinking with Qubes” the reality is that sensitive data is handled in untrusted qubes. Whether that is an accidental global paste, or accidentally going to a site on the wrong Qube, I’d wager that this has happened to most all of the not fully disciplined users. I even have times where I knowingly handle sensitive data on untrusted qubes, but that’s a risk I have to take because isolation isn’t possible in some scenarios. Lastly, just because a qube isn’t “trusted” doesn’t mean I want an open door. I’d like to have individual qubes not to be soft targets even if they are for handling potentially dangerous code. And as a bonus, I think good guest security is a starting place for many things that otherwise wouldn’t be possible, and if nothing else would be a starting ground for other things. TOR comes to mind, as anonymity is pointless (and probably broken anyways) without security. E.g., if someone gets to my chat logs, then that would be bad. It’s not practical to have 25 different qubes for each chat.
Tl;dr I’d like to see Qubes actively encourage guest security, as it an provide a layer against the hypervisor being a single point of failure, and I just don’t like the idea of VMs used for dangerous activities being easy targets.
Discaimer: the team has seemed to get better about this, with effort integrating SELinux on Fedora and by admitting that having open-door qubes maybe isn’t good. I also understand that this can be seen as worth the risk of a little redundant security to scavenge some usability on a system that has a steep learning curve.
First, I understand your reasoning, at least in part.
However, I have a few comments on that as well.
Ultimately, the user decides what level of privacy, anonymity, or security they consider appropriate for their needs.
Of course, one can always strive for improvements, but they go in different directions. One person wants more privacy, another more anonymity, and another would like more user-friendliness and automation.
Especially with QubesOS, it’s clear that different users’ goals conflict with each other. The goal must be to find the best compromise, not the best security at the expense of user-friendliness, or the best user-friendliness at the expense of anonymity.
I hope I’ve made myself clear in these few lines.
In any case, the goal here must be to make Qubes easy to use for as many people as possible, not to replace Qubes with something else.
It’s natural for human beings to try to transfer responsibility for their own actions to others, so they wouldn’t blame themselves for the consequences of a self committed wrongdoings. If I was Qubes dev, I would never take the responsibility to “fix the security” of other qubes’ OSes.