Hi,
I can’t seem to find an answer to this question: is there any point in swapping the basic template from fedora-40-xfce to kicksecure-17? Does it make any sense to do so? Why is the kicksecure template not in the qubes repository by default and not preinstalled by default?
I’ve searched all over the internet, the qubes forum and have not found answers to the above questions
There is an additional hardening in kicksecure compared to fedora and it’s up to you whether you need it or not:
There is an additional hardening in kicksecure compared to fedora and it’s up to you whether you need it or not:
Hi,
I know what the kicksecure project is and what its objectives are. The question about whether it makes sense to replace the fedora-40 template with the kicksecure template - you didn’t answer it 
Nobody except for yourself can answer this question.
For some people using Qubes OS instead of Windows doesn’t make sense.
Everyone have different needs.
I’ve never taken a look at Kicksecure, but reading Kicksecure - A Security Hardened Linux Distribution I do not see strong incentives for using it if it does not integrates well into Qubes OS.
Most security hardening does not seem very relevant to me when using as an AppVM on Qubes OS. Of course, it can be a bit better than Fedora 40, but if the price is to lose Qubes OS integration (update check, qubes RPC, firewall etc…), this is not interesting.
Although Fedora may also have hardening that is not present in Kicksecure! Like SELinux, compilation flags used for packages and system defaults. A list is here, you need to compare against Kicksecure for your use case now Security Features - Fedora Project Wiki
@apparatus is a valuable member of the Qubes OS community and clearly not a troll. Their reply was about the fact there may not be good options as kicksecure may hinder your workflow, or not even provide what the security you were looking for.
1 Like
@solene,
Wouldn’t the loss of Kicksecure integration with qubes be fixed by installing the qubes-vm repo and installing qubes-vm packages in the kicksecure template?
At what point is there an actual loss of integration with qubes, since kicksecure can theoretically be installed in an existing debian-12-xfce template?
Assuming that an attacker could exploit vulnerabilities in sys-net, sys-firewall and get into other VMs by taking advantage of undetected vulnerabilities in XEN itself - wouldn’t hardening templates, including sys-net and sys-firewall, be an appropriate response to this type of threat?
AFAIK whonix is based on kicksecure. So it’s already available. Even with a Tor browser ready to go.
Btw, it seems funny to me to flame someone as a potential troll and emphasise the “technical and deep” nature of the question while at the same time asking for “opinions”. There is no “opinion” on security/trust/availability. @apparatus gave all the guiding facts: What “secure” means depends (as a fact) on someone’s needs.
[1] Kicksecure for Qubes
[2] Kicksecure for sys qubes and sys-vpn? - Qubes - Kicksecure Forums
1 Like
no idea if they work
theoretically 
This is assuming a lot. If XEN is compromised it is game over anyway because dom0 can do anything, like reading the qubes memory from the hypervisor which defeats any mitigation.
A much more realistic attack would be that you run in a qube some untrusted code containing a malware and that it tries to take control of the qube (either silently or not), then some mitigations can help. But there is already a passwordless sudo by default, so root escalation protection are not very useful. And escalating to root does not help much as the appvm resets all the files outside the home directory upon reboot, and altering the user files does not require root.
On Qubes OS, using disposables will mitigate most security related problems you can encounter in real life, given you are not a target where someone will prepare payloads just for you which is more complicated to defend against.
But won’t just hardening the template help to reduce Dom0’s compromises?
Theoretically, the permissions of the executed code could be limited by AppArmor.
AppVM uses system files from inherited template anyway, and usually the holes detected and exploited are static. The most greedy bites are holes that have not been detected. Since it is possible to compromise Dom0 and AppVM, why not assume that Dom0 has been compromised? Should we trust Dom0 in a zero-trust context?
This depends, you need to have the correct hardening against the according threat. Kicksecure and Fedora may have different hardening, so it is hard to say which one is better.
Kicksecure is definitely aimed at hardening the system, while Fedora - like Ubuntu - creates a compromise between usability and security for general use of their distribution.
I have installed kicksecure on the debian minimal template and it seems to work fine. You can still use the qvm- tools it seems. I did not try the qubes backup as I have my own backup system.
As for passwordless sudo, from what I can tell thats not strictly required for qubes to manage a qube. I commonly don’t configure it in the templates I build form deb minimal (deb minimal template does not have passwordless sudo by default).
I think hardening the templates is a bit of a side show for qubes itself. it makes sure you can’t break out of the virtualization layer, what happens inside it is a bit up to the user.
i have to doublecheck this but im pretty sure if you go the distro-morph route, kicksecure wont have passwordless sudo by default