mushix99
Secureblue has been around for a tiny fraction of the time Kicksecure but has done far more and has a roadmap of doing much more than they already do. Kicksecure removed most of the hardening they provided, is based on a distribution that's a terrible starting point for it and does not have the privacy or expertise expertise to do much. The person who was adding most of the hardening to Kicksecure left and isn't going to be active in the project again. The lead developer of Kicksecure has views and methods incompatible with providing good privacy or security. It's a stagnant project not doing anything significant. It would be easy for someone to make a Whonix replacement with drastically better security using a better base and actual hardening.
It seems Kicksecure has similar kernel hardening features as secureblue.
It doesn't provide any significant kernel hardening. Sysctl configuration can barely do any hardening at all. Enabling hardening requires building the kernel with a different configuration to enable the upstream hardening features such as CFI and adding patches for stuff that's not upstream. This is not an area where secureblue does much yet according to their documentation, although that might be outdated, but it doesn't mean they won't.
https://www.synacktiv.com/en/publications/exploring-grapheneos-secure-allocator-hardened-malloc is good coverage of hardened_malloc. It should be noted that what the Kicksecure developer did is send off a bunch of requests to use hardened_malloc to various projects without explaining it or why it would be useful, then he used the negative response to unexplained feature requests by developers expecting someone to tell them why this would be useful as an attack on hardened_malloc. The situation demonstrates their dishonesty, manipulation and overall highly untrustworthy behavior.
https://www.synacktiv.com/en/publications/exploring-grapheneos-secure-allocator-hardened-malloc is a good article explaining hardened_malloc beyond a couple minor things: it misses the write-after-free check for non-MTE and doesn't properly explain the difference between Scudo's 16-bit CRC32 inline metadata checksums vs. hardened_malloc having 8 byte random canaries with a zero leading byte for the non-MTE case. The canaries in hardened_malloc are simply padding between allocations which is random per slab because it can be and has a zero leading byte to block C string overflows. In Scudo, it's a CRC32 checksum to protect the inline metadata which incorporates a global secret and the address. hardened_malloc could use a calculation to combine the address or slot number into each canary but it would be fairly pointless. The canaries are mostly only checked on free, which is often too late to stop an exploit from a linear overflow anyway vs. MTE catching it immediately and deterministically with how hardened_malloc uses it.
The mistake in Whonix making these attacks on GrapheneOS is that
SELinux in general probably is a more flexible and stricter MAC than AppArmor, with policies being added in a more consistent way throughout whole Fedora system, whereas AppArmor profiles are provided only for several apps.
AppArmor is barely used to do anything.
Both projects are conscious about and have overlaps in various topics like setuid, permissions, capabilities.
Kicksecure barely does anything about any of this.
There is a section in above link about, why hardened_malloc has been abandoned by Kicksecure.
The reason they did this was because they were called out about their behavior by GrapheneOS after repeated attacks on us. Kicksecure spreads a bunch of misinformation on their website and began spreading misinformation about GrapheneOS after dropping it. Dropping an important security feature and denying it worked properly or was useful because they're angry at us shows a lot about the project. They also could have avoided repeatedly attacking and spreading misinformation about GrapheneOS. They did that over and over, then seemed shocked we were angry with them. You can find them doing this on their site.
Trivalent seems to be a great Chromum-based hardened browser, similar to Vanadium. It is known, that Chromium outperforms Firefox sandbox in terms of security, but not all use cases demand browser usage.
Firefox is a very bad choice as a starting point but particularly if it's not going to be improved at all.
For sure Debian has weakened security with default settings. But I'd assume hardening options like applied from Kicksecure (or manually) can make it more comparable to distributions like Fedora or secureblue?
Debian's poor security largely comes from the very poor updates and immense amount of trusted packagers. It's a complete disaster in terms of getting privacy/security patches and supply chain security. There are an extremely large number of people who are highly trusted. Many of those people have extremely untrustworthy behavior and actively do things which are very problematic with their power. There are endless political battles internally but people aren't really pushed out because of it, so they stay around holding grudges and even actively trying to sabotage other work. Look into how many people are trusted and the endless internal turmoil about things like systemd.