Recommended guest OS for security

General Discussion
1

Hi,

I am trying to decide which distribution / OS to use for my Qubes VMs. I have read a few discussion regarding this on the mailing list, but it does not seem like there was any conclusion, so I am hoping to get some answers/suggestions here :slight_smile:

Ideally, I would want something minimal, has a small attack surface, but is still easily maintainable. So far, here is what I current understand:

Fedora
Compared to the likes of Debian, Fedora ships more up to date packages and has less downstream patching. Even with the 6 month (1 whole release cycle) behind Fedora version Qubes ships in the stable repository, Fedora packages are still generally more up to date than what’s on Debian’s stable repository, which is a plus.

However, it does look like that SELinux is currently non-functional, and the fact that the repository metadata is not signed could be a risk.

Debian
Generally, I do not want to use Debian at all. Their packages are very outdated, and as far as I know, they only fix bugs that have a CVE filed. I get nervous thinking about the bugs that do not have a CVE or bugs that they refuse to fix/hold back until the next Debian release. I also know that while the repository metadata is signed, the packages are not.

However, I am also aware that KickSecure exists. Their security-misc package is particularly helpful, especially with out of the box sysctl hardening, a large kernel module blacklist, SUID removal, etc. Their hide-hardware-info.service does work nicely on NetVMs as well. I can replicate a lot of these on a normal Fedora template, but that will require a lot more effort on my part compared to just relying on someone else (who is a security professional) to maintain the security configuration instead.

The lkrg-dkms package being available on the KickSecure is a plus, as I do not want to keep track of version updates and manually compile the kernel module myself. The same thing goes with the hardenedmalloc package, it’s nice just heaving it being automatically available.

Oh, and AppArmor works just fine too.

Arch
With Arch, I get the benefit of getting updated packages with minimal downstream patching like Fedora, and I can (or at least I think I can) get AppArmor working. I could also replicate some feautres of security-misc, but again, that would be a bit more work than just relying on someone else to maintain it.

The obvious downside with this is that Arch is not officially supported, I don’t know if the Qubes Updater works with pacman or not, and even if it does, dealing with AUR packages like hardened_malloc or lkrg-dkms would still require additional maintenance work from me. There is no concept of “meta packages” or distro upgrade either, so if a package in the software sttack becomes deprecated/obsolete, I wouldn’t notice.

OpenBSD/HardenedBSD/Mirage
I don’t know much about these operating systems / unikernels. I saw some posts arguing that they would be better than Linux for something like sys-net or sys-firewall, but then again, they are not officially supported, and I would imagine maintaining the system with them would be hell. Take Mirage for example, it is not availble as a package on any repo, and I wouldn’t know when to rebuild/redeploy it. Or take OpenBSD/HardenedBSD, does the wrapper even work with their package managers? Do I need to check for updates manually?

Overall, I am torn on which operating system to pick, for which purpose. I want something that at least has decent security so Xen wouldn’t be the only thing that’s protecting me. I don’t mind spending a lot of time setting the system up, but once it is up, I don’t want to spend a lot of time maintaining it.

2

How about this?

For Debian based template for security:

  1. Kali
    Installation may go to dom0 terminal and insert this command ‘qvm-template-gui’
3

While I agree with you on most thing,Arch can be a BIG headache at times and there are times that even Arch packages and keyrings get all jacked up. If you do not stay on top of Arch it will break very easily

4

Could you explain why kali is more secure than debian?
As i know that kali use debian sid or even experimental on some packages.

5

Here is my explanation about Kali.

When you are using Kali, it is based on Debian for actual security just like Parrot and Kicksecure. However, Kali has some system flaws for some upgrade because of some packages cannot fully upgrade from its current versions. On the other hand, you can still use Kali as your hacking OS for the security pentest for your network system security firewalls. You can also use Kali for tutorials for people how to hack with Kali within Qubes. As of today (2022-05-27), Kali can be use for anything to see any CVEs within all of the OS’s design limits. You may use Kali as your template Qube for any AppVMs for disposables and put those records within your vaultVM.

6

Q: How is security handled for unstable?

A: Security for unstable is primarily handled by package maintainers, not by the Debian Security Team. Although the security team may upload high-urgency security-only fixes when maintainers are noticed to be inactive, support for stable will always have priority. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable.

https://www.debian.org/security/faq#unstable

1 Like
7

As for an mirage-firewall it is slowly on it’s way to qubes-community. Why isn't the Mirage Qubes Firewall available as a Qubes Template in the upstream repos · Issue #115 · mirage/qubes-mirage-firewall · GitHub

8

With all due respect, I do not think that’s how it works.

What I am looking for here is defensive security, for attack surface reduction, security mitigation, application sandboxing, up-to-date packages or at least packages with the security fixes, etc. I am not looking to do penetration testing, and I am not going to pentest every part of my system on a daily basis (and I highly doubt most people will do it either).

In the context of just running GNU/Linux on your computer, as far as I know, Debian is the worst major distribution in terms of security. They ship outdated packages, they generally only fix CVEs and they don’t even fix all of them. They let packages which people frequently use such as Chromium or Firefox-ESR (yes, not even normal Firefox, Firefox-ESR) go EOL. Debian’s defaults are pretty insane too - like putting microcode update in the non-free repo and not having it installed by default. I do not know where your claim of “based on Debian for actual security” comes from.

Debian Unstable, while has more up-to-date packages, is not handled by the Debian Security Team, as @tzwcfq pointed out. It is a suboptimal system at best.

KickSecure, as far as I know, is based on Debian because of historical reasons and the fact that they can keep up with Debian’s changes (since Debian is a slower moving distro). There are discussions on their forum about moving to a more sane base, though no progress has been made so far due to the lack of contributors. Even their own security researcher say how bad Debian is: Linux | Madaidan's Insecurities.

Kali Linux, to the best of my knowledge, is literally Debian Unstable + lots and lots of penetration testing tools. Unlike KickSecure (which has legitimate security hardening configurations), all Kali does is increasing the attack surface with the vast amount of unnecessary packages bundled in. Correct me if I am wrong here, but I do not see why anyone would ever want to use it on any system, disposable, or app VMs. This recommendation looks very anti-security and anti-stability to me.

1 Like
9

Have you thought about CrowdSec?

10

Yeah, I don’t see how it is helpful though.

For one, it is badness enumeration. You can’t rely on it for any real security (What does an IP blacklist even do? What if the threat actor just gets a new IP and connect to my computer anyway?). I also do not like the idea of having yet-another-privileged-app on my system, collecting logs and submitting it to some random server.

Would you recommend that the user install an Antivirus on the system? How about Suricata or Snort? These can only give you an indication that something suspicious is going on. They cannot prevent a real attack at all. They are relying on pure luck. If you are not recommending these, then why would CrowdSec be a solution to anything at all?

I would rather have something like more AppArmor profiles, Bubblewrap profiles with a syscall whitelist, stricter SELinux policies, etc. Something substantial, providing security in a systematic and meaningful way.

1 Like
11

Does SELinux or AppArmor work when user has passwordless access to root?

12

They are still good for system daemons that do not run as the user. Granted, both solutions are very limited (practically non-existent for desktop apps), but it could be better if someone makes more policies/profiles. Proper policies can also prevent an app from executing another binary or easily do privilege escalation even if the user has can elevate themselves to root without a password (or so I think).

Regardless, I replace passwordless access to root with the dom0 prompt or just outright not have privilege escalation for the user user with minimal VMs anyways. There is no need to be root in AppVMs at all.

13

See here: Debian-10-minimal Configuration

and here: automate debian-minimal based template creation

14

Here are my thoughts for creating my new kernel because I already planned out with my own cautious details:

15

It’s a trade-off and you need to make a choice:

  • You put your trust only in distribution maintainers security team that they will check all the packages for possible malicious changes but don’t include possible non-CVE security fixes.
  • You put your trust in thousands of different packages maintainers that none of them will include malicious code in their releases but maybe you’ll get non-CVE security fixes.
1 Like
16

I highly doubt it.

For one, something like Firefox has millions and millions of lines of code. The same thing goes for the Linux kernel and the like. Are we to believe that distribution maintainers will catch malicious code in these projects should one be introduced? I don’t think that’s very likely to happen.

Two, let’s assume for a moment that the maintainers can magically catch all malicious code and that they backport fixes with CVEs. What happens then? Packages like Firefox-ESR and Chromium going EOL is still horrible. Even with some backported fixes, you do not want something like an old browser, so old that it’s deemed EOL by upstream. I cannot find a threat model where this makes any sense.

At the end of the day, the trusted parties are still:

  • Library Developers
  • App Developers
  • Whoever maintain your packages

Neither option removes trust of any of these entities. The difference is that in one option, you get all of the fixes and newer software to play with. The alternative is using outdated software with only some backported fixes for the sake of “stablity”, which might not even hold true.

17

I can do the same thing with Fedora Minimal, and I’d still get newer packages on Fedora. The only difference is that I can maybe get some hardening configuration from KickSecure by morphing Debian into it.

18

Sorry if I didn’t make myself clear. They don’t perform source code audits of all the packages (though they do have some packages audit). But they review the security patches for packages in stable repo.
So if the maintainer of some package insert malicious code in his package and release it then if you’re on rolling distribution you’ll be hit by it after you update but if you’re on stable distribution then you won’t be affected by it.
And for some packages like browsers you can put your trust in them and always can install the latest versions that are not in stable repo. This way you’ll have latest browser fixes but won’t be hit by some calculator package maintainer inserting malicious code in his package.

1 Like
19

This is yet another reason why Fedora is superior to Debian (outside of hardening configs provided by KickSecure and the fact that SELinux is currently non-functional on Qubes) in my opinion. On Fedora, you don’t have to make such trade off.

This is not to mention, the stability of the system may suffer if you mix match new packages with old packages. This is like using Arch then enabling partial upgrades for some packages or using Fedora then enabling the Rawhide repos for some packages. I don’t think it’s that great of an idea - you really do not want an inconsistent system.

20

You don’t have to make that trade-off by your own choice because this choice was made by Fedora maintainers. But it doesn’t mean that there is no trade-off.