Is there some sort of comprehensive guide on hardening RHEL clones like Alma and Rocky?
I have read Madaidan’s blog, and I plan to go through CIS policies, Alma and Rocky documentation and other general stuff like KSPP, musl, LibreSSL, hardened_malloc etc.
But I feel like this is not enough and I will likely face problems that I cannot solve. Instead of trying to reinvent the wheel by myself, I thought I’d ask if anyone has done this before so I can use their guide as a baseline. Maybe there’s a community guide on hardening either of these two? I’d contribute to its maintenance if there is one.
Thanks.
Look mom, I’m famous! :P
Thank you!
The best you can do in regards to that is adding my profile to your preferred RSS reader, so you get notified each time I post. A few good ones for android are Feeder, Read You, or (my favorite) Capy Reader.
I’m not sure if you mean actual Kicksecure or if you mean Whonix. Either way, if I were to use Qubes OS, I would do Whonix inside of Qubes (until a secureblue template is made).
secureblue backports a lot of fixes from other projects (e.g. their browser, Trivalent, backports fixes from GrapheneOS’s Vanadium). Their team is small but mighty.
GrapheneOS compartmentalizes as well, but in a different fashion. All apps on GrapheneOS are sandboxed, Once GrapheneOS implements App Communication Scopes, apps will be able to be completely* isolated. Without App Communication Scopes, the best way to isolate apps is by setting up separate profiles.
*While APC prevents communication between apps, they are still installed on the same profile, and thus have access to unique profile identifiers. Apps with network access can technically communicate with each other via a third party. Furthermore, apps may be able to directly communicate with each other through a telephone effect (e.g. Pixel Camera tells Google Play Services to tell Google Calendar about the photo you just took). I am massively oversimplifying this, but you get the gist.
I mentioned in my post that security is going to become very interesting with the introduction of the Linux terminal into Android. If GrapheneOS chooses to expand on this, that means, like Qubes OS, GrapheneOS could emulate multiple Linux distros.
Anyways, this is how I would rank them in terms of security (again, oversimplified):
GrapheneOS > Qubes-secureblue > Qubes-Whonix > secureblue
Each project fundamentally has different goals, so there is no one “security” to rank them by.
Though, for desktop, I prefer secureblue, as I don’t have a secondary GrapheneOS device, and secureblue is far more usable than Qubes OS.
Thanks for the tip, love Capy.
You’re right, Whonix is probably the better idea. I use kick secure now but if I move to Qubes then I’ll use Whonix as a default.
I’ll have to read more about secureblue. I haven’t given the documentation as much time as I should have. I guess you could run an HVM for now.
Why do you rank secureblue over Whonix?
Whonix on its own isn’t very secure. It’s more privacy focused than security focused. It’s based on Debian, which has a host of issues I won’t get into.
dom0in Qubes OS is based on Fedora for its security, and it’s no coincidence that secureblue is also based on Fedora.Dom0 being based on Fedora has been a gripe of mine for a while now. Fedora isn’t that secure without some effort either. Unfortunately, I have no way to confirm which one out of them is “more secure”.
Do you have any sort of automated test framework in mind which one can use to test distros against attacks?
Fedora’s philosophy is being a modern and security oriented (not security focused) distro. An easy example is that Fedora uses Linux kernel 6.14.2, whereas Debian uses Linux kernel 6.1 (I know they backport fixes, but the point remains).
Generally trust what security experts say about it, but if you really want an automated test, you can look at Lynis