My knee-jerk reaction to installing IDS in dom0 is that it’s got far more costs than benefits, mainly because the benefits are close to nil. AFAIK, IDS detecting an attacker in dom0 would already be far, far too late.
Using the engineering swiss cheese analogy I made in the compartmentalization thread, the attacker would have had to pass through all the pieces of cheese to the last and most important piece that controls everything else. That’s a lot of missed opportunities for earlier detection, and having dom0 access would open the doors to many ways of evading detection, in my uninformed opinion. An attacker with enough competence and resources to make it this far wouldn’t let an off-the-shelf IDS trip him up. It’d be like an invader getting to the gold in Fort Knox, then screwing up by slipping on a banana peel.
Basically, I believe a compromised dom0 = GameOver™ and that banking on detection of this after the fact doesn’t do much to justify whatever cost the IDS incurs.
(As usual, I must add that I’m not a technical person, so I might be mistaken about some things.)
I’d agree with the general gist here: once you’ve done all you can to
secure your DomU’s and employ good trade craft (OpSec) in the way you
use your computer and other technology … THEN geek out about Dom0 and
ME as much as you want.
once you’ve done all you can to
secure your DomU’s and employ good trade craft (OpSec) in the way you
use your computer and other technology … THEN geek out about Dom0 and
ME as much as you want.
People who focus only on dom0 are kind of like kings who focus only on protecting the throne room.
On this topic, a big problem is that the official Qubes documentation and the default configuration seem to go out of their way to discourage users from securing DomUs. A prime example is Joanna’s “WTF” rant copied into the docs from the old version of /etc/sudoers.d/qubes (copied in its full glory below).
On that note, I strongly support the idea of having sudo prompt as the default in Qubes, not passwordless root, and don’t think I’m in the minority. If WhiskerMenus vs XFCE menus warrants a poll, this key security issue surely does too.
user ALL=(ALL) NOPASSWD: ALL
# WTF?! Have you lost your mind?!
#
# In Qubes VMs there is no point in isolating the root account from
# the user account. This is because all the user data is already
# accessible from the user account, so there is no direct benefit for
# the attacker if she could escalate to root (there is even no benefit
# in trying to install some persistent rootkits, as the VM's root
# filesystem modifications are lost upon each start of a VM).
#
# One might argue that some hypothetical attacks against the
# hypervisor or the few daemons/backends in Dom0 (so VM escape
# attacks) most likely would require root access in the VM to trigger
# the attack.
#
# That's true, but mere existence of such a bug in the hypervisor or
# Dom0 that could be exploited by a malicious VM, no matter whether
# requiring user, root, or even kernel access in the VM, would be
# FATAL. In such situation (if there was such a bug in Xen) there
# really is no comforting that: "oh, but the mitigating factor was
# that the attacker needed root in VM!" We're not M$, and we're not
# gonna BS our users that there are mitigating factors in that case,
# and for sure, root/user isolation is not a mitigating factor.
#
# Because, really, if somebody could find and exploit a bug in the Xen
# hypervisor -- as of 2016, there have been only three publicly disclosed
# exploitable bugs in the Xen hypervisor from a VM -- then it would be
# highly unlikely if that person couldn't also found a user-to-root
# escalation in VM (which as we know from history of UNIX/Linux
# happens all the time).
#
# At the same time allowing for easy user-to-root escalation in a VM
# is simply convenient for users, especially for update installation.
#
# Currently this still doesn't work as expected, because some idotic
# piece of software called PolKit uses own set of policies. We're
# planning to address this in Beta 2. (Why PolKit is an idiocy? Do a
# simple experiment: start 'xinput test' in one xterm, running as
# user, then open some app that uses PolKit and asks for root
# password, e.g. gpk-update-viewer -- observe how all the keystrokes
# with root password you enter into the "secure" PolKit dialog box can
# be seen by the xinput program...)
#
# joanna.
Honestly I’m not sure about the value of IDS nowadays though. Considering
most (incl. malware) traffic is TLS encrypted nowadays and one usually doesn’t want to mitm/break TLS for oneself except in very specific cases, an IDS nowadays doesn’t do much more than checking for “bad” DNS requests and IPs. You can also do that with netflow sensors and keep all traffic data pretty much for forever (1MB per day or so).
Side Note: Proxy VMs are quite useful to break TLS if needed… I succeeded with sslsplit.
The ‘new generation’ of IDS might be running in a privileged VM: https://drakvuf.com/ - for Xen
or (Trend Micro) Deep Securtiy - for VMware
Thanks for mentioning that one as I didn’t know it and it looks promising!
It probably opens up a few attack paths as well, but might be worth it under certain circumstances.
“People who focus only on dom0 are kind of like kings who focus only on
protecting the throne room.”
Who suggested this?
Securing dom0 is a key part of securing a Qubes system, and using some
IDS is a good way of monitoring the system for changes in dom0.
I see no evidence that Qubes “goes out of its way to discourage securing
DomUs” - nor does it go out of its way to give a false sense of security.
If you are able to correctly configure and use security hardening tools
then you are free to do so - if you have good support then a naive user may benefit from this, but the default position is aimed at enabling
naive users to benefit from Qubes. Many distros have access to root from a user account - look at Ubuntu
for one, (despite the requirement to enter user password).
Wouldn’t that thread be a general Linux security thread? Not that I’d be against it–I have much to learn and a thread on the topic (perhaps resulting in a guide) would be enlightening.
I was agreeing with Sven saying that one should focus on securing domUs before thinking about securing dom0. Some people (naive users) focus too much on dom0 since know enough to understand that a compromised dom0 means GameOver™ (the throne room is important) but not enough to understand that securing domUs is the first and arguably most important defense for dom0 (the best way to secure the throne room is by securing the kingdom).
For naive users, a sudo prompt provides far more benefits than costs.
All that’s required is smashing the ‘Enter’ key when the prompt shows up–it therefore costs almost nothing.
On the other hand, the benefits are potentially large (assuming I’m correct that a domU with passwordless root is more vulnerable than one with sudo prompt).
As usual, I’m not technical, so I’m open to being wrong
Wouldn’t that thread be a general Linux security thread? Not that I’d be against it–I have much to learn and a thread on the topic (perhaps resulting in a guide) would be enlightening.
I was agreeing with Sven saying that one should focus on securing domUs before thinking about securing dom0. Some people (naive users) focus too much on dom0 since know enough to understand that a compromised dom0 means GameOver™ (the throne room is important) but not enough to understand that securing domUs is the first and arguably most important defense for dom0 (the best way to secure the throne room is by securing the kingdom).
For naive users, a sudo prompt provides far more benefits than costs.
All that’s required is smashing the ‘Enter’ key when the prompt shows up–it therefore costs almost nothing.
It’s hard enough to get users to check what is on the screen without training them to smash the enter key when a prompt appears.
On the other hand, the benefits are potentially large (assuming I’m correct that a domU with passwordless root is more vulnerable than one with sudo prompt).
It’s the assumption that a qube with passwordless root is more
vulnerable than one without that I don’t accept, but let’s agree to differ.
As always, there’s a trade off between security and usability - I think
the current model works well for most users, you draw the line in a
different place.
Some changes in Qubes I have not accepted - e.g, the removal of filtering
on tinyproxy - and if this change were made it would be one of those for me, and those I work with.
Great topic! perhaps, the IDE would need to be tested to provide hashing outputs after every run and compare its results with the previous outputs. This will only check for changes in dom0 and check for gaps.
However, if an issue was discovered; how would we solve it?
Can we just swap a dom0 for another dom0?
Or is there a dom0 available in a repository that is stable and easily installed? i.e. Thus not using an update as that might not fix the issue per say, as that would most likely fix any vulnerabilities previously discovered.
If a clean, updated and hardended dom0 was available to download and install; some of us might feel more at ease in case exploit.
Perhaps, there is and I haven’t read enough to find it and install it.
the IDE would need to be tested to provide hashing outputs after every run and compare its results with the previous outputs
That is how the old tripwire was working - however if anybody tried to use it for a real production service… may knows that this is just not a viable solution in practice.
However, if an issue was discovered; how would we solve it?
In case of a dom0 compromise? - that is a game over.
It is hard to accept, but to compromise dom0 there should be an already compromised domU AND several 0 days (or just not patched) bug/vulnerability in any of:
hardware
BIOS/UEFI
hypervisor
kernel
so simply swapping out the dom0 is a very optimistic way to ‘solve’ a dom0 compromise.
In such situation you better of replacing your hardware, and recreating your whole digital life from scratch.
We run tripwire on production servers, and it still seems workable to
us.
I run tripwire on (some) qubes and in dom0 on some machines. Again, it
seems workable.
It’s old venerable, not old decrepit. And, of course, there are new
variants on the theme.
As to network IDS, I don’t know if anyone has yet tried out opensnitch
from the packages I posted. I’d be interested in feedback in the Qubes
context.
We run tripwire on production servers, and it still seems workable to us.
And how many ‘exception’ folders you have?
Not to mention if you run it on a live system how do you trust the results?
(As if your box is compromised the attacker can give you a fake result)
In my opinion such filesystem checks can be trusted only if you mount it on another system and do the scan there… which is just not possible most of the time.
But, I not questioning if it is works or not, but how much resource you need to ‘use’ compared to the benefit you got…
Yes.
Control in dom0 gives you full control over the system configuration,
the ability to run arbitrary commands in any template or qube, and access
to all data stored in qubes.
The only circumvention would appear to be using an encrypted qube - I
see “appear to be” because this provides no protection. An attacker from
dom0 would just wait until the qube comes online, and then copy the
(extremely sensitive and now unencrypted) data in to another qube, and
then bring that off the system as they choose.
This doesn’t rely on the attacker having permanent access to dom0 - just
long enough to drop an automated tool.
Argument for an IDS in dom0.
This thread reads like 6 people arguing about 4 different things. So let’s get one thing straight, dom0 being compromised is NOT game over (sadly); it is extremely bad, but it can get WORSE by you not knowing about it getting compromised at all and carrying on with the business as usual. This is where IDSs come into play.
For an IDS to be even worth talking about (imho) it needs an option to immediately inform the user in an immutable form once it thinks the compromise has taken place. Unless using some kind of specialized hardware where you can blow up an efuse or something, this will almost always mean employing a second device - a printer, a terminal, anything connected to a serial line really.
As to where the IDS needs to go, you could install one in a proxyvm to analyze your network traffic, but that would only detect a relatively unsophisticated attacker, which is not whom we need to worry about. More on that below. This means we are left with the kind of IDSs that work more like a traditional anti-virus, by using a mix of signature and heuristics based detections of changes to the operating system in real time. I am not aware of any anti-malware/IDS solutions working on Xen natively. Which in turn means it only makes sense to install it in dom0 (and eventually additional copies in domUs we consider extra important).
The toughest decision to make is to what software actually pick. Forget the surface of attack for a second, let’s assume they are all equally (in)secure. Actually let’s imagine we found one that doesn’t increase said surface at all. Will it actually work though? Haven’t heard of any QubesOS specific malware so far, we are talking about targeted attacks here. If somebody took time to exploit your browser/e-mail client/whatever, your kernel, your xen hypervisor, what kind of IDS you can put up that they will not be able to bypass? This is why I think any IDS included in QubesOS by default or one widely accepted and used by its community will be as useful as sudo password prompt.
That leaves one with only two realistic (somewhat) options, even if some IDS gets bundled with QubesOS at some point: get a lightweight open source integrity checker and hope for the best, or make your own custom solution. If you go with the former, make sure it has a way of reporting the intrusion to you that an attacker will not be able to reverse (so again, a printer, a terminal, a simple circuit with some diodes connected to a serial port etc.). Be aware it will probably only work once, if the same attacker compromises your dom0 again they will be ready. As for custom solutions, that’s a long and complex topic, but on a high level, instead of trying to monitor the whole OS for changes which gets very hard very fast, one could try just introduce very small changes to the system itself, by patching system libraries or its kernel itself. This, sadly, is not a very accessible solution.
It is really not. Other people already elaborated on that so let me just add this: if there was a reasonable way to “secure” an domU OS we would have no need for anything like QubesOS. domUs are assumed to be easily compromisable and so effort was made to have them be easily replaceable to the point of being disposable - because that’s way more secure of a solution than any kind of defense you can implement from inside of domUs. dom0 on the other hand is intentionally stripped of functionality to reduce the surface of attack. If an user were to put any thought and effort into securing anything, dom0 would be THE place to start, period. In QubesOS instead of installing or reconfiguring software, this could take a form of increasing physical security, taking time to separate domains properly etc.
(As usual, I must stress my lack of technical credentials and welcome any corrections)
The IDS that you mention and the IDS that I assume the thread is about seem very different–while I talk about off-the-shelf IDSes, which most people will have the ability to install, you seem to be describing something completely custom made for the purpose of detecting those who intrude Qubes OS dom0, as it involves dom0-specific positioning (and immutability that involves breaking dom0 isolation).
Now, I won’t dispute that such an IDS would be valuable and a net positive, assuming its creator can make a bug-free IDS that won’t end up costing her more than it’s worth, but if it was this important, the developers would’ve come up with some sort of bundled package already, but this would be an ineffective, ad-hoc solution for reasons you yourself have provided.
You raised a point that has come up before, which is that an intruder sophisticated enough to reach dom0 would be equipped to sneak past whatever was set up in the throne room. It may be argued that adding a diverse combination of defenses and detection --throwing as many obstacles in the attacker’s way as possible-- will increase the cost of attack and the likelihood of a trip-up, but the exponential increase in attack surface that comes with this is a very real cost, and is why I think one shouldn’t set aside the issue of attack surface, or else you’ll end up endorsing confused stances like this one, assuming by “securing” you mean installing IDSes and more:
Rather than rebutting individual points, it’s easier to write out my stance: domUs are assumed to be compromisable, hence the extensive compartmentalization, redundancy, and disposability; but the Qubes security model is built on the security guarantees that Xen represents–Xen is the bedrock of Qubes. If Xen were to be turned against the user, the Qubes security model turns to dust. If one assumes that dom0 has been compromised, assuming one hasn’t made risky changes to it, it is safe to assume that Xen has been penetrated and it’s GameOver; you’ve been owned. This is why it’s more important to secure domUs than it is to secure dom0, because its security is underwritten by Xen and Xen alone, and the way to attack it would be via the exposed domUs.
A dom0 that is breached is a symptom and not a cause. While detection is important, prevention and earlier detection is much more important, and those are done with domUs. The fact that detection of a breach of the throne room requires immutability (involving un-isolating dom0), and even then isn’t guaranteed, makes the benefits small compared to any costs incurred.
However, using the bedrock argument, one can also make the argument that since dom0’s only vector is Xen, one can afford to increase its conventional attack surfaces (assuming what you install doesn’t contain or create intentional or unintentional vulnerabilities). I’m not so sure about this part, and would be grateful if anyone could point out flaws in it or my stance in general.
. Also another one for how to secure domUs.