Qubes won't warn me If my Dom0 got compromised

General Discussion
1

  • I’ve read a lot about qubes, but I can’t seem to find anything on how to know if my system has been compromised.

  • If I use any Linux distribution or even Windows, I can install antivirus and it will notify me if I have Malware or Ransomware (Actually It should, but it won’t :sweat_smile: ).

  • For qubes why I can’t receive any message or notification warn me to take my precautions.

  • Is it true that Qubes cannot identify malware or ransomware?

    Why do you believe it will be difficult?

2

I haven’t installed Qubes yet, but I researched. Is there anything bad about installing an antivirus app in an app template? Something that doesn’t sell all your data and acts like malware itself like the typical ones. Have you seen this thread?

1 Like
3

Malware has to enter Qubes by entering a qube, i.e. normally an AppVM, and that is where you should try to detect it. That means, you should install an antivirus app in a template (mostly in a Windows template, because that is where most viruses will enter). Updating this antivirus product may be somewhat tricky, because templates should never be connected directly to the internet.

In this scenario, all AppVMs based on that template will be checked for viruses. AppVMs based on other templates, standalone VMs and dom0 will not be checked. But: Current viruses will not be able to infect templates or dom0, because these are never connected to the internet, and no untrusted software should be installed there. Most viruses entering an AppVM will be destroyed on restart of this AppVM, and none of them can jump to another VM or even dom0, if they are not specifically designed to use a bug in XEN - and such viruses are currently unknown (but not impossible).

Infecting dom0 would require

  • a virus able to infect a Fedora system - possible, but improbable
  • entering dom0 via executing this virus in dom0; for that it has to
    • either jump from an AppVM to dom0, which would require a major security hole in XEN
    • or installing untrusted softwarein dom0, which would be a severe user fault - users should never do that!

So, installing antivirus software in dom0 would probably reduce its security, instead of improving it.

1 Like
4

See also:

1 Like
5

There’s no way to know this for certain in all cases. This isn’t some missing feature of Qubes OS. Rather, it’s an inherent limitation of all the modern computer architectures that you’re likely to use in the real world as a regular person.

There are some things that antivirus (and similar security software) can detect and address, but they can never provide 100% assurance that your system is “clean.” Far from it. Any suggestion that they have this magical ability is just marketing that preys on common folks’ ignorance about infosec.

You do, but only for the things that matter and that are within Qubes’ control. Qubes doesn’t try to BS its users by pretending that it can do more than it can. We leave that to proprietary software that makes money by overpromising and underdelivering. As an open-source project, we have the luxury of being brutally honest with you about Qubes’ limitations (and everyone else’s), because we have no financial incentive to sell you a bill of goods.

There is no built-in antivirus software, but you can always install it yourself, if you want.

2 Likes
6

I think the best approach, fitting Qubes mindset but being setuped externally, is linked to this comment I posted and should get more traction from community and developers: https://github.com/QubesOS/qubes-issues/issues/4371#issuecomment-761863958

The idea here would be to have a dom0 that doesn’t change between updates and qubes creation, having anything else related to config libs and binaries outside of the dom0 domain.

That way, prevention could apply, inclusing dm-verity setup and verification from open source firmware prior of OS boot. That is, pre-os security. Not linked directly to secureboot per se, but having qubes provide the mechanisms so that dom0 can be inspected, with or without binary blobs (or antiviruses or other closed technologies/obscure mechanisms relaying on something or the other). The best is always to have known states to compare to.

You would then know if a metadata check returns a change. And could basically have checksumming and detached signature, implemented inside of Heads or other firmwares to check and report on new files having been changed/newly deployed and have a possibility to investigate those changes and do an conscious decision on sealing those changes on way or the other.

Best, in opinion, is to be able to have audit capabilities to be able to act upon. Believing an antivirus would catch something is not a prevention mechanism and will mostly always fail with targeted attacks not fitting signatures or evading behavioral analysis done per antivirus. But malware has to reside somewhere. That somewhere is vast, it can be in memory, disk, firmware. But the prevention mindset is to limit what goes into persistent memory the best possible. And considering dom0 compromise being game over needs to be known. Having dm-verity active on dom0 would fit the bill effectively, but for that to happen, some output happening in dom0 needs to be externalized.

Once that is done, having a read only dom0/outside of updates/user changes, using OS as templates, just like qubes works, is the way to go. That and using disposable qubes for all activity where untrusted code can run, only having volatile consequences. If that is done and dom0 changes, and pre-os security is implemented to keep track of integrity measurements of dom0 externally (/boot is a good place. Would be easy to implement in Heads), we would know for sure that dom0 has not changed. If firmware hasn’t changed, Xen and kernel hasn’t changed and dom0 hasn’t changed, templates haven’t changed… Then using Qubes just got even better!

The whole idea of continuing with the mindset of running untrusted code in trusted environment should stop here.

Prevention and compartmentalization is all Qubes has to offer, where linked comment above gives a direct path for concrete action on what is missing for actions to be taken to measure and verify additional states.

If everything changes all the time in dom0, it’s hard to differentiate what is normal from what is not without having to measure and verify everything against digests and integrity validation, which is costly thing to do.

Insurgo

2 Likes