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.
Madaidan’s Insecurities hasn’t been updated in a few years, so some of the information is a bit out of date. It is still decent information, but don’t follow it granularly. What you may be looking for instead is secureblue, which essentially does what you are describing but for Fedora Atomic desktops.
From secure blue’s website:
Why do they say that? What limitations does Linux have in terms of security?
https://privsec.dev/posts/linux/linux-insecurities/
That’s a more up-to-date article about security issues with Linux.
TL;DR is that Linux (the desktop, not the kernel) is fundamentally insecure, and so the more secure options for desktop are Qubes OS (Qubes OS is not a Linux distro) or (even better) GrapheneOS used in Desktop Mode. secureblue is about as secure as Linux can get, but the most secure option for desktop itself.
Things also get weird when you consider running secureblue inside of Qubes OS. See my post for more thoughts about that.
Hey, I recognise you now! That was a great post, I had a lot of fun reading it. If I could follow people on Lemmy I’d follow you.
What do you think about Kicksecure (and Kicksecure inside of Qubes)? I know they are criticised for backports but leaving that issue aside, I think they have created a very handy distro. I personally go through CIS benchmarks for most of stuff including Kicksecure but it’s definitely nice to have a prey hardened distro (SecureBlue too but I hear SecureBlue isn’t a big team, not sure how much time they have to address the broad range of desktop Linux security issues).
Honestly, Qubes is the best at this by far. Their method of compartmentalisation takes away the complexity of reasonable security from the end-user making it a mostly seamless experience. I personally think that if you were to put GrapheneOS and Qubes OS side-by-side on uncompromised hardware, I’d take Qubes. I’d run GrapheneOS inside Qubes with a software/hardware TPM passed through if I could.
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
Unless you have an unusual threat model, this statement is utter nonsense. I can run a kconfig stripped kernel with zero kernel modules and one userspace process that is completely audited and trusted, without the ability to spawn even other processes or talk to network (because the kernel lacks support for the IP stack).
Secureblue might offer something significant when compared to other popular and easily usable tools, but if you compare it to the theoretical limit of Linux security, its not even comparable.
I examined Secureblue’s kernel parameters and turned multiple of them off because some were mitigations for something that was unnecessary. IE: The kernel would make the analysis that your hardware is not affected by a vulnerability, and thus there is no need to enable a specific mitigation. But they would override this and force the mitigation, so you take a performance hit, for what I understand to be, no security gain. Not sure why they did that, a mistake? Or did they simply not trust the kernel’s analysis for some reason? Who knows.
You’re right, secureblue isn’t quite there when talking about security on desktop/server Linux.
Is desktop linux more insecure than Windows? I know it’s less targeted, bit is it technically more insecure? Are secureblue and grapheneos more secure than a hardened OSX / Windows?
This is an impossible question to answer without more information. Depends on your threat model, how you use the computer, your distro, etc.
In which threat models are Windows & OSX more secure than Linux?
A threat model in which you don’t trust the Linux Foundation and volunteers but do trust Microsoft.
Its all about what you want to protect. If a security breach is worse for you on Linux than it is on Windows because of which party has the data, then for you, Windows might be more secure.
Some people get confused because they think there is some objective measurable security rating one can apply to a system for every person. There isn’t. We may use the same systems but have different threat models and thus rate the security different.
Thank you for that. Yes, I only really follow his post roughly.
Unfortunately, I don’t think secureblue is going to be a possible choice. I like the secureblue project, I think it’s awesome but what I’m working with will likely only come with a Rocky/AlmaLinux base.