Intrustion Detectors in dom0: bad idea?

“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

1 Like

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.

2 posts were merged into an existing topic: WTF?! Passwordless Root Access in VMs?

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.

3 posts were merged into an existing topic: Implications of Dom0 Available in a Repository

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? :slight_smile: - 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.

1 Like

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.

1 Like

We run tripwire on production servers, and it still seems workable to us.

And how many ‘exception’ folders you have? :wink:
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…

Tripwire? Could you elaborate on this a bit more? thanks,

I hear game over a lot. I don’t know if that’s an accurate depiction
of what a dom0 intrusion would be.

Think of it this way: once an attacker has reached dom0 you are in the
same situation as if you’d be running Windows or Mac OS or any other Linux.

Hence, from a security perspective: game over.

1 Like

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.

2 Likes

(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.

1 Like

I revisited this thread and noticed this paragraph. Would you mind sharing your custom dom0 IDS here? Of course, I’d perfectly understand it if you said, “No”.

Ok I don’t have an IDS running in dom0 but I think It may have been comprimised – how can someone prove this if they are not running some kind of IDS in dom0?

Incredibly difficult, because you have no idea what to trust.

You could try rpm -V -v which will confirm that binaries are unchanged
from the package that installed them
Of course you are trusting that rpm itself hasn’t been altered by a
malicious agent. You could work round this by using a fresh copy of
rpm taken from a machine where you are confident. Then you’ll need to
confirm that the packages you are testing against are the genuine
packages.
And by this time you are kicking yourself for not having protected
yourself before the (suspected) breach.

An alternative approach would be to look for evidence of compromise -
watch outgoing connections, look out for changes in policy files, or
strange activity. Depending on what’s happened you may or may not be
lucky and find evidence. Thing is, you will never know.

You cant risk any Qubes tools, or indeed any binaries on the compromised
system. You cant just restore backups on a fresh system because you cant
guarantee that the Qubes backup tool hasn’t been hacked to subvert the
data structures, and may impact on a clean install. (Unless you know
when the compromise occurred.)
If you genuinely think dom0 is compromised, the best you can do is this:
Boot a live distro on another machine, image the Qubes disk to another
disk. (If you genuinely think you have been compromised, don’t use either
machine again.)
On another machine, boot up, attach the cloned disk, decrypt the Qubes
drive, and then save what data you can from the private store of
your qubes.
There’s less risk if you use simple data representations - much easier
to hide something in a complex data structure than in a plain text file.

Remember, what counts is your data, not your qubes or templates.
If you have salted your system then there is no need to worry about not
having backups of your templates or qubes. You can resalt a fresh
install and get the system back, and the restore the data - and it’s the
data that counts.

In a nutshell:
Protect your system.
Take regular backups in, and outwith, Qubes.
Salt your qubes.
IDS in dom0.

Hope for the best and prepare for the worst.

Wouldn’t a better approach be instead having a IDS AppVM to which dom0 periodically pipes other VMs? Along the lines of this post:

That has merits but doesn’t address the specific question - how can
someone prove dom0 is compromised if they are not running an IDS.

I think we are way beyond the point of what to do if? When I notice dom0 gorging on CPU, I’m worried. Has anyone used this script other Plexus?