How about this?
For Debian based template for security:
- Kali
Installation may go to dom0 terminal and insert this command ‘qvm-template-gui’
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
Could you explain why kali is more secure than debian?
As i know that kali use debian sid or even experimental on some packages.
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.
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.
1 Like
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
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.
3 Likes
Have you thought about CrowdSec?
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.
2 Likes
Does SELinux or AppArmor work when user has passwordless access to root?
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.
1 Like
Here are my thoughts for creating my new kernel because I already planned out with my own cautious details:
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
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.
1 Like
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.
1 Like
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
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.
1 Like
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.
1 Like
I’ve been thinking about this exact question lately. Thus far, I didn’t come any further than what you wrote here. Could you share an update on your thoughts about this?
1 Like