I think basic concept of Qubes OS security is missed here. Some of answers here
For example, a buggy web browser running in a Qubes domain could still be compromised just as easily as on a regular Linux distribution. The difference that Qubes makes is that now the attacker doesn’t have access to all the software running in the other domains.
etc…
Hello!
Thanks for the documentation, I’ve really enjoyed reading all this!
Please correct me if I’m wrong, is it safe to conclude that a typical Fedora - app VM such as untrusted domain has minimal level of security defined by the policy and that, as you mentioned, compromising it would be a trivial task of exploiting a buggy web browser, just like in any other OS. By doing this, the untrusted app vm will become owned by an attacker.
But despite “security-by-isolation” approach, this VM is still connected to the sys-firewall which has a direct link to the network stack including the dom0. So all of this looks a bit horrifying from my perspective.
Would it then make more sense to limit the capability list (permissions) to all untrusted domains? And why does the “user” in the untrusted app - vm even have the capability to perform sudo operations? I’m not arguing why we use Passwordless root, my question is why do we need sudo to browse web in the first place?
The thing is that despite all the documentation that I’ve read and my own experience with this system, I still don’t get the point of sharing the same security policy across all templates / domains and letting the end user to decide what is safe and what’s not.
Finally, if an attacker could in fact exploit the untrusted vm trough a buggy browser, what’s really there to stop him from doing the same to any other qube including dom0? Do we rely on fact that (dom0 is detached from the network), and that it “can’t get compromised” by an error in configuration or bug … ? if so, do we really need the networking to simply start an interactive shell?
Finally, If the end-user do not have the efficient instruments to identify/prevent intrusions (such as Snort, Selinux, or better …), how will he even know that the system was compromised in the first place?
The complexity of Qubes implementation is obvious, I truly admire the effort, and despite all the risks, Qubes is still the true spaceship from the distant future among operating systems and with just a little bit of hardening it could become the perfect enterprise solution!! 
Thanks!
Are you running a browser in dom0?
An attacker should only be able to attack your untrusted domains, e.g. you don’t run your web browser in your trusted domains.
Every user’s needs are different, so it makes sense to ship, for example, the default Firefox configuration. If you think something is truly unsafe, you should report it to the upstream developers of the respective packages.
In the meanwhile, if you wish to harden firefox, you should check out my guide: [Guide] Automatically install extensions and configure new (dispvm) Firefox profiles with arkenfox user.js and policies
Or harden your VMs with kicksecure: Hardware information masking and spoofing with hypervisor - #5 by BEBF738VD
Using Qubes OS instead of any other OS is arguably already a big security improvement.
You can create minimal templates which, by default, do not include the qubes-core-agent-passwordless-root package.
An attacker should exploit a Xen vulnerability.
The one would need side channel attack for this, which is way less trivial.
You now have all answers here, try to understand them, not to oppose them.
@gehekal580 - This was an interesting question, that got dropped in favour
of the far less interesting “honeypot” fork, and Epistemology 101.
I’d like to go back to the original questions, and put in my thoughts.
As a long term Qubes user you’ll be aware that Qubes aims to ship
templates that honour the base distro. There are a couple of FAQs on
this, and on shipping specific software or configurations.
If you use a Fedora template then by default you get Firefox as it ships
with Fedora, warts and all. If you want to change that profile you
can, but your changes may not suit other people, and may make it more
difficult for them to work in Qubes.
Of course it would be possible to ship a version of Qubes that (e.g) has
no passwordless root, (for those bothered by that), shut down firefox
profiles, restricted applications in network connected qubes, and so on.
It would be straight forward to do this.
It would be equally feasible to offer this as an option at install -
there’s been a long standing discussion about offering such flavours of
Qubes, and installation options.
The main problem that I see with this is that, (if the Forum is any
guide), many users are incapable of understanding what would happen if
they select these options, and of working within the confines they
selected. As evidence, you can look at the many questions arising from use
of minimal templates, despite the major warnings in the documentation
about using such templates, or from users of Debian testing.
If you make these things available, then what support will be offered to
the ordinary users who choose them, on the reasonable grounds that “more
secure” is bound to be a better thing?
I should say that I like the idea of shipping a “hardened” Qubes for
those that want it, but I would ban users of it from raising issues at
GitHub or in the Forum.
I think that the typical Qubes end-user does not have the skills to
handle this. I do not think that the typical Qubes end-user needs to
handle this. I’m not even sure what the typical Qubes end-user looks
like.
The decision to ship a standard configuration as used in the base distro
seems to me to be a reasonable compromise between security and
usability.
And Qubes makes such compromises all the time.
That is a major if.
In fact, it would be instructive to look at that baseline in the context
of Qubes.
The first thing to note is that the baseline is applied against an
online qube.
One of the “high” severity, and three of the “medium” severity fails
relate to use of IDS/AIDE.
This is a topic that has come up in the Forum a number of times. It
is not an easy one to solve. Would users really want an IDS in every
qube? What would be the point in a disposable? Who would configure it,
and where would the alerts be amalgamated and reported to the user?
What would the average user do with this amount of information?
Perhaps AIDE should only be configured in the most important qubes.
Which ones are they? As you acknowledge, Qubes gives users the power to
work up new templates and new qubes - each user will have different
priorities and different views about which qubes should be protected.
You might think this is wrong: sometimes I do.
(I run tripwire in selected qubes and dom0, and monitor network traffic, but I
recognise that this is not for every one.)
Another of the “high” severity, and thirteen of the “medium” severity fails
relate to use of passwords, and authentication.
You must know that in Qubes, such considerations play no part. It’s not
that you cant put in passwords for user accounts in qubes. But if you do
everything becomes clunky and the seamless use of qubes is a distant
memory.
What is the advantage of having password protected user accounts in individual qubes?
What added security does this bring to Qubes?
Again, these issues have been raised before, and they may be worth
pursuing. Often, when they come up. it is because people want to
protect their qubes against some one who has access to their machine,
and it’s often linked to having some qubes encrypted.
In my view, this is just wrong. The issue shouldn’t be whether someone
with access to dom0 can access your qubes, but whether they can access
the data in those qubes. That’s a protection that you can put in place
immediately without instituting any password policy per qube.
Four of the remaining medium fails relate to logging. Again, in the
context of individual qubes this is moot. There are open issues about using
a centralised log server, or of making qubes logs persistent, but there
is not, I think, consensus on whether or how to do this. For most users,
logging in individual qubes (particularly template based and
disposables) is pointless.
The remaining medium issues are simply pointless in Qubes. NTP is not
used, because there is a separate mechanism for setting time in
individual qubes, which is more efficient in the context of Qubes.
Looked at in this way, the judgement is not bad, and any one with
experience of Qubes should be able to see this.
The VMExec service can be dangerous, but it is not allowed by default
in disposables. It is allowed when called from a qube to a disposable
created by that qube - again, this is a convenience feature.
My view on this is not shared by others. The end user should be
responsible because it is they who want to be secure.
I don’t think that it is possible to have an OS that is secure for users
without any training in it. There are OS that aim to be secure by
restricting users actions: in my experience naive users are repeatedly
trained in their use and monitored for infractions. That isn’t what Qubes
does.
I do not think that Qubes is only for the leet, or that you have to have
extensive CLI knowledge and skills. I know many users who have little
Linux knowledge and are productive in their use of Qubes, and far more
secure than they would be with a monolithic system. They are able to do
this because they recognise their limitations, and prioritise their
security.
There are, as I have said, ongoing discussions around flavours of Qubes,
but the idea that there would be one size fits all security policy
levels is one that needs extensive argument and justification.
Thanks for starting this discussion.
If we make some progress in it, then I’d be happy to work toward a
Qubes flavour that addresses specific issues.
I find it useful in any discussion of hardening, to first recap the fundamentals of Qubes OS usage as I see them:
Looking at the above, I am not sure how much I care about hardening in a “bang for the buck” kind of way. Yes, all of the above rests on the assumption that the attacker doesn’t have a XEN/Qubes OS zero-day. I am comfortable with that. If that residual risk is too high for your scenario you probably shouldn’t rely on an internet-connected computer at all.
I am confident I can explain the above rules to pretty much anyone by asking them to imagine each qube as a separate computer (including the disposables as one-time-use computers). Most people will be able to grasp and apply this model.
About the browser: I Brave with the “shield” set to not allow scripts or cookies by default as well as tracking and fingerprint prevention cranked to the max. That’s 4 toggles set once. Again, I am confident I can explain that to everyone. I use this even in my disposables. Now if I arrive at a site that’s not working, very few clicks (on the shield) are needed to make it work. It’s just enough of a hurdle to make me remember:
I am not arguing that hardening is always futile or unnecessary, but I am convinced that using Qubes OS in the first place improves the situation already very much.
A rather low-effort help might be just to provide one or more additional templates; just like there are now templates fedora-xx-xfce and fedora-xx-minimal, some template fedora-xx-hardened could be offered for those willing to use it. Surely there could / should be a lot of discussion about the contents of such a template.
Here’s just an example or a configuration that I use for teaching mainly non-technical people - simple, but just a first step:
Mein Deutsch ist schlecht, aber ich [that diagram] verstandet[?]. Scary. Enough cognates I could figure it out.
That was just a quick suggestion. Now, having a bit more time, I changed the texts to English:
Some explanations:
untrusted is just the standard qube coming with the Qubes installation, based on the standard Fedora template, but with Thunderbird removed. It is intended for surfing arbitrary locations and may be at risk from some websites. Consequently, it does not keep any valuable data and has no facilities to view or edit office documents.
personal is used to access only trusted websites, and the firewall rules for this qube restrict it to these locations. It is based on an extended Fedora template containing additional software like LibreOffice, Gimp, Wine, and some Windows applications. Any office documents from this qube are only opened in dispVMs in order to reduce the risk of infection.
work is based on the same extended Fedora template and is the qube used to edit documents - even MS office documents. It has no netVM and so the risk of an infected document contacting a hacker’s control server is minimized.
Windows is the workhorse used to execute anything I need for my teaching. It is based on a Windows 7 template with QWT installed. In order to reduce the risks for such an AppVM, and possible risks caused by it, its internet access is limited, again by a firewall rule, to the server of the teaching institution (udis).
whonix is just the standard AppVM based on the whonix-ws coming with the Qubes installation. It is used for all accesses over Tor and could as well be replaced by a dispVM.
vault is the key part of Split GPG, just as described in the Qubes documentation, keeping my private PGP key.
storage finally is a qube based on the standard Debian template and, having no applications and no network access, it is used explicitly and only for permanent data storage, and it is the only qube whose data are regarded as valuable and worth keeping. The Fedora-based qubes might even be configured as dispVMs, and, if you are willing to accept the rather slow start of Windows (about 1 minute on my laptop), even the qube Windows might be created as a dispVM.
This is a rather simplistic design, intended to show that with a minimum effort a decent level of security can be reached, and it is a first implementation showing how you can compartmentalize your digital life, as described in the Qubes documentation. Once the templates are in place and Split GPG is installed, setting up this structure takes only a few minutes, but it is much more secure than, for instance, a Windows 10 installation based on the (quite terrible) German SiSyPHuS studies, which are quite useless for a practical environment.
On the other hand, teaching such a structure to non-technical people shows them a way to improve their security at a relatively low cost, and may even help to show that Qubes need not be complicated. Compared with other solutions, this is a rather simple and highly effective way to build and use a reasonably secure environment.
Using this configuration is also quite easy for a beginner. All they see is a panel with some icons. The color of these icons is a hint where, for instance, Excel will be running or which data storage is accessed. Starting the required environment, i.e. qube, is done automatically and transparently for the user, and forbidden functions, like accessing the net from the work qube, are simply not there.
This is something that even rather unsophisticated users could masster.
I didn’t intend it as a criticism, I was just surprised I could read the Deutsch version.
Are you proposing the default install do this, or is the idea here to be able to guide the new user through the process of turning the default installation into this? Or is this solely meant as an example of what QubesOS can do?
I know that now, leaving aside Whonix, there’s basically one template (per Linux flavor that is–there’s one Debian template and one Fedora template) that includes everything on it, and it is used even as a template for sys-net and sys-firewall, so those qubes end up having libreoffice, firefox, thunderbird and keepass installed. This of course does nothing to discourage a new user from using those apps in those qubes! (Perhaps future installation scripts could clone the included template, and do dnf/apt removes as appropriate–that shouldn’t add too much to the size of the ISO though it will lengthen the time it takes to install.)
I note the diagram glosses over sys-net and sys-firewall…but I think in this case it’s probably appropriate since too much detail all at once will confuse people.
Hi, I am glad that you had success there. German surely is a difficult language - even the Bavarians don’t manage to learn it! 
With regard to the installer: I would prefer to keep it as it is now: a general basis for configuring the system to one’s needs. I see my description more as a possible local adaptation, like the ones described in the “Getting started - organizing your qubes” section of the introduction to Qubes. Perhaps I will add a chapter there sometime.
You’re right there. Perhaps I should explain a bit about where this diagram comes from. Currently, I teach the enhanced security coming from compartmentalization at two levels:
At the first, basic level I just describe the idea of separating our digital life into separate security domains, which are protected against each other. At this level, I try to convey the concept of such security domains. At this stage, where I use this diagram, I do not even talk about Qubes, virtualization, and technical system structure. I just show that I get to different environments when clicking on some colored icon. The idea behind this way of presenting the system is to make the students comfortable with the underlying concepts, without needing to know many technical details. So even the non-technical ones should get the feeling that they can master such an environment.
After that presentation, I go into the implementation, present Qubes, and show that these abstract security domains correspond to virtual machines. At this level, I can speak of things like templates, netVMs, firewall rules, and dispVMs, and the possibility to build a suitable structure from available building blocks.
This is still somewhat experimental, but so far the feedback is positive. The students get the feeling that they can work in such an environment, and the non-techies among them see that they could get appropriate help from technical personnel.
Starting directly from Qubes, as I did previously, often had an intimidating effect and created a feeling that it all was too complicated and scary. Let’s see how it works out in the next courses.
Absolutely agree. This reminded me that with absolute beginners I went even more backward teaching them MS Office. Bringing them some old desktop case, dismantled it in front of them teaching them what each component in it to which part of their organization refers, then how Windows refers to the real organization, then how folders and files refers with the real compartments and their content, then how Windows Explorer helps with that, then promising them when they learn Windows Explorer and its commands they will learn at least 30% of any other software, finally to get to the Office.
And I was spending about 30% of the courses just to get to the point to open Microsoft Word which turned out to be great investment which led us to have 10-20% time of the course to show their self-creativeness.
None of them, as far as I know, ever flooded their desktop anymore, but kept it clean.
Underlying effect we didn’t discuss was a layer of responsibility (meaning security) they got as a base for future advancing to their needs and wishes.
If I am reading your “offtopic” paragraph correctly, you showed them the nuts and bolts first, then taught them the front end.
That’s actually the exact opposite of GWeck’s approach, he shows them the front end first, then drills down to other things. If I wanted to emulate his approach with Word and Windows, I’d probably show them file manager and introduce them to the hierarchy of folders, Then show them how to get there both via explorer and the save-as and open dialogs in Windows. Then I’d do an introductory document in Word…then maybe jump back to explorer and move the file around to different places, copy it, rename it, open it up again so they can see nothing changed except where it’s being filed and under what name and then (maybe) delete it. At that point they can now navigate the abstract “filespace” well enough to manage their documents, they can create one and do rudimentary things to it. Then they know enough to really start learning Word.
Your point about teaching them about the file system before getting into word is a good one; it never occurred to me that lacking that is probably why so many desktops get cluttered. But I’m not sure if I’d go so far as to open up a box for that first lesson! [Second lesson: Why you want a D: drive even though Micro$haft tries very hard to hide the concept from you. Third lesson, those phony folders that are really combos of actual folders; which is why I don’t use them because I don’t know WTF the system is actually doing with my documents.]
[In Windows and even sometimes Linux I pick up some clutter over the yea rs simply from having a document that doesn’t “fit” in any pre-existing place and I am in a rush and defer figuring out exactly what to create for it to go into. But that means maybe four columns of icons in ten years and a lot of those are put there by software I install. I at least won’t have that issue in QubesOS as my qubes don’t have desktops, most disappear in a cloud of smoke when I shut them down anyway, and one shouldn’t work on documents in dom0.]
This looks like a good approach.
(And I am sure there are plenty of other places in Germany where they can’t figure out how to speak auf Deutsch! 
)
I would like to see that discussion here. Customising existing templates
is relatively simple to do - determining what should go in to them,more
difficult.
@Sven it probably wont surprise you to know that I follow the same
approach as you.
This isn’t the default install, and requires some configuration and
effort on the part of the user.
I have salted this in the past, so I’ll dig out those formula and post
them for review. The one area I am sure I am lacking is in browser - I
do not use bookmarks or history, and have not reviewed split-browsers - is
that approach workable and intuitive? If not, how should this be best
dealt with?
One area that I think can be hardened out of the box is qrexec policy -
e.g, setting deny policy for the vault rather than ask. Does any one
else have views on this?
It’s you who shaped my thinking more than any other community member. The pupil following the ideas of the teacher shouldn’t surprise anyone.
I haven’t looked into split-browsers either and are afraid I have little to add and are bound to repeat myself. I can and have made arguments for and against all kinds of browsers, but in summary I would boil it down to:
I use Brave mainly for performance reasons, but it has the added advantage that limiting scripts, tracking and fingerprinting are core features and do not require additional plugins. They’ve also made it very easy to set the defaults and adjust them on a per site basis so it doesn’t feel like a chore or gets annoying.
There are no scripts or salt to set this up. After generating my templates I simply create my online-dvm, launch it and make my most restrictive default settings in the profile without ever visiting any website. This becomes my template for disposables and I also clone from it for the more specialized qubes that will hold state. When I visit such a site for the first time I then use the shield icon to allow scripts for that specific site and maybe non-third party cookies.
I imagine one could automate the creation of the the qubes and placing the restrictive default settings / profile.
