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?
Hi I was wondering if anyone could go through the steps for getting tripwire working in dom0?
Since dom0 has no Internet connection, or gcc, I settled for compiling in a qube and then transferring to dom0 but ran into problems: “./bin/siggen missing.”
‘sudo qubes-dom0-update tripwire’ doesn’t work?
Edit: rpmfind suggests that tripwire started to be available with fedora 32. So, yes you’ll probably have to build yourself.
That’s wrong - it’s available (2.4.3.5-1.fc25) from the updates
repository.
sudo qubes-dom0-update tripwire will work. That will install - as to the
steps to getting it running, I don’t know of a guide, but I’m sure you
can find one with minimal effort.
The idea is that you build a policy of directories/files that you want
to scan, and what “differences” you think important. The scans are
stored in a database.
The default policy file tells you the basics and shows you what will be
scanned. You will need to tune this file.
A few repeated scans, and you will see many reports, that you will
need to consider, of files changing during use. You will have to tune
the policy to reach a balance for usability.
Keep the policy and database offline.
If you need help with the details, ask away.
No one said this was easy.
(As I said, I use tripwire from familiarity - there are alternatives.)
2 Likes
Thanks for correcting that. I shouldn’t have answered from my phone without checking myself. Will do better in future.
It wasnt you that was wrong.
You do very well as is.
1 Like
the trip wire cli command seems very interesting. I wonder if I mess this up can I revert back to a previous version of dom0?
Recovering dom0, doesn’t seem that transparent, you have to copy all the files that are outside of the home/ folder nor are the installed configuration packages backed up. Unless, you copy them over to the home folder and reinstall those packages. (as least that’s what the documentation says.)
So, if you wanted to remove the current dom0 because (by some accident the trip wire wasn’t installed properly) how would you do it?
Subsequently, how would you install a previous version of dom0?
Do you delete first? then recover? And how would that work? Don’t you need dom0 to accomplish these functions?
I know, it’s seems odd, however, I want to make sure I don’t mess anything up without being able to reinstall dom0.
thanks,
Hi @Libertad,
installing and uninstalling software in dom0 (as long as it’s in the
official repository) can easily be done like this:
sudo qube-dom0-update tripwire
sudo dnf remove tripwire
Regarding “restoring” dom0: if you feel like you “messed up” dom0 or
it’s in any form compromised your only reliable way is to reinstall
Qubes OS from scratch.
If you have recent and verified backups of all your templates and qubes
that’s not really a big issue. But it could take many hours depending on
how much data it is.
Yes, the dom0 backup only contains your home directory. Think about it:
you feel you “messed up” so why would you want to restore that “messed
up” state? Instead you are starting with a clean, default dom0 and you
can then step by step redo the customization you want.
I safe copies of the config files I touch in dom0 within my home
directory for that purpose (e.g. the policy files I’ve touched).
My recommendation to you would be to try out and get familiar with
tripwire in a (fedora) qube. Then when you know what you are doing,
apply this knowledge to dom0. Your dom0 is not the place to do
experiments. Also an IDS is not a think you just install and then you
are “protected”. You have to monitor it and understand what it is
telling you. So there is no shortcut.
1 Like
Thanks for your suggestions. What I get from your answer is:
1st copy all config files if you are able.
2nd, place them in the home directory.
3rd backup.
4th, Revert back to a version of qubes which is verified and safe(which includes dom0).
However, what you are also saying it’s not impossible to swap out dom0s.
Obliviously, if I could, i would reinstall qubes, but In my case, It’s not an easy task…
It’s easier to delete dom0 and then reinstall a previous version and then add trip wire. But again, how would you do that? DomU perhaps?
the other question I have: is about the security updates? How are those managed with tripwire?
I’am not as experienced as you but I would really enjoy having a few extra machines and days in the week to experiment with dom0.
I can’t afford leaks or intrusions anymore, that’s why I like the concept of the trip wire.
thanks,
There was another thread talking about dealing with dom0 compromise -
there are no shortcuts here, if you really think your machine has been
attacked.
Depending on the nature of the attack, and your threat model, you may
need to start from scratch on another machine.
You should always be prepared for complete loss. (Not necessary due to
malicious intent - cat on the keyboard, bug on the motherboard, weather
event, solar flare, …)
If you can, it’s worth having a backup machine under lock and key that
you periodically sync with your live box. If you cant do this, have
everything ready (configuration, backups, data etc), so you can be up
and running as quickly as you can.
It’s worth thinking about, and prioritising, your qubes. If your main
machine becomes unavailable, what would you need immediately to be
able to get going again.
This is where sensible use of Qubes backup comes in - don’t blast
everything together. Break down your needs, and backup accordingly.
And remember, it is the data that counts - not the qubes. I would
always suggest having an encrypted backup of vital data alongside the
Qubes backup. If it comes to it, and you don’t have time/money to get a
new Qubes box up and running, you should still be able to access your
data quickly and easily.
On tripwire, Sven’s suggestion is good - you can practice in a qube, and
then transfer to dom0 when you are happy.
Tripwire monitors changes to your system, so it will record any changes
because of updates. If you scan before and after an update, you should
have a record of all changes made.
Keep in mind that many machines have a card reader that is attached to
dom0. You can store the tripwire binaries and configuration on an SD
card, as well as the tripwire database, if you will.
3 Likes