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.
this post was submitted on 16 Apr 2025
29 points (91.4% liked)
Linux
53368 readers
840 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
From secure blue's website:
Who is secureblue for?
secureblue is for those whose first priority is using Linux, and second priority is security. secureblue does not claim to be the most secure option available on the desktop. We are limited in that regard by the current state of desktop Linux standardization, tooling, and upstream security development. What we aim for instead is to be the most secure option for those who already intend to use Linux. As such, if security is your first priority, secureblue may not be the best option for you.
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.
Hey, I recognise you now!
Look mom, I'm famous! :P
That was a great post, I had a lot of fun reading it.
Thank you!
If I could follow people on Lemmy I’d follow 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.
What do you think about Kicksecure (and Kicksecure inside of Qubes)?
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 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
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.
I personally think that if you were to put GrapheneOS and Qubes OS side-by-side on uncompromised hardware, I’d take Qubes.
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?
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. dom0 in 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 isn’t that secure without some effort either.
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).
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?
Generally trust what security experts say about it, but if you really want an automated test, you can look at Lynis
secureblue is about as secure as Linux can get...
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?
Is desktop linux more insecure than 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.
What do you want to achieve exactly?
Different requirement can lead to different approach.
What do you mean? I want to harden it in a general sense against exploitation
What does that even mean? What kind of exploitation are you talking about?
Every use case comes with its own risk, and every risk needs to be handled differently. People jokingly said that if you wanna be sure, don't connect your computer to the network at all; and if you wanna be surer, don't use a computer. While that was a joke, there's truth in that.
If you're just going to use it as a workstation, then firewall to make sure some randos don't ping you should suffice. If you're sharing this workstation with your tech illiterate mates, then perhaps something to prevent executing random stuff like SELinux or AppArmor would do. If executing random stuff is just what you do, then set up VMs or some other ways to isolate that execution environment.
If you're sharing files directly from your computer to the internet (e.g. with SMB or NFS), then you'd need to make sure only the right people have the access, and the auth can't be brute-forced (i.e. with rate-limiting and lock-out policy). Same goes if you allow remote login (i.e. thru SSH). Some people use custom port number to obscure their stuff, and you can do it too, but do keep in mind it could make your life (or your mates' lives) harder.
If you're running other outward facing services like SQL database or HTTP, that would require different ways to address. If you're on such level, you'd want do some serious readings.
You raise a valid point. In which case, I want to try and prevent malicious privilege escalation by a process on this system. I know that's a broad topic and depends on the application being run, but most of the tweaks I've listed work towards that to an extent.
To be precise, I'm asking how to harden the upcoming AlmaLinux based Dom0 by the XCP-NG project. I want my system to be difficult to work with even if someone breaks into it (unlikely because I trust Xen as a hypervisor platform but still).
I admit I was a bit surprised by the question since I've never consciously thought about a reason to harden my OS. I always just want to do it and wonder why OSes aren't hardened more by default.
Privilege escalations always have to be granted by an upper-privilege process to a lower-privilege process.
There is one general way this happens.
Ex: root opens up a line of communication between it and a user, the user sends input to root, root mishandles it, it causes undesired behavior within the root process and can lead to bad things happening.
All privilege escalation is two different privilege levels having some form of interaction. Crossing the security boundary. If you wish to limit this, you need to find the parts of the system that cross that boundary, like sudo[1], and remove those from your system.
[1]: sudo is an SUID binary. That means, when you run it, it runs as root. This is a problem, because you as a process have some influence on code that executes within the program (code running as root).
Thanks. You are correct, however since root is required for certain processes, I will use different users and doas for my needs.
I have realised that it is hard for me to justify the reason why I want to harden an OS for personal use. I gave privilege escalation out, but after reading your comment I have realised that that is not the only thing I am looking to "fix". My intention with running hardened_malloc was to prevent DoS attacks by malicious applications trying to exploit unknown buffer overflow situations, and LibreSSL and musl were to reduce the attack surface.
I agree with your comment though. I'm just wondering about how I can specify a reason (and why such a reason is required to justify hardening of a distro). I haven't found much of a reason for the existence of OpenBSD, Kicksecure, Qubes etc other than general hardening and security.
That narrows it down a lot. To be honest, I'm not familiar with that. However, with that specific of a topic, it shouldn't be that hard to look up for articles to follow and come up with a course of action.
The reason why OSes aren't 'hardened' by default is because it would be a real pain for users trying to set things up or use it for daily operation. If you take it to an extreme, they wouldn't be able to access anything they want. If you're a sysadmin, you'd be faced with your whole office pissed off because they wouldn't be able to do their work.
Last but not least, what does 'hardened' mean anyway? You can have something as 'hardened' as an airgapped workstation in a faraday cage with an off-grid power supply. Are you running away from a government agency? I wouldn't think so. So a firewall blocking unused ports and mindful practice should suffice.
Same as any other distro. Best practices.