Also 17 year old vulnerability:
FreeBSD has recently faced significant vulnerabilities, including a 17-year-old remote code execution flaw in its NFS service
this post was submitted on 07 May 2026
-29 points (19.1% liked)
Linux
13571 readers
406 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
Please show us proof of code in the Linux kernel and in FreeBSD kernel that would suggest Linux is more susceptible to exploits. How about explaining SELinux to us and the equivalent in FreeBSD and how they compare. If you can't, why make assertions of things you should have the self awareness to know you don't know and understand?
FreeBSD is way better in security record
After accounting for the massive difference in number of eyeballs actually looking for vulns?
Uhm .. no.
Linux had permissions from day one, neither Windows nor Apple did until much more recently.
I use Apple, since there's many versions of its OS and only¹ the one based on BSD has permissions.
The entire Linux ecosystem is permissions based, it's baked into the kernel and while bugs continue to be discovered and patched, they're visible to everyone, where that's not the case with either Windows nor Apple.
Permissions aren't new. Unix has had them from the early days, as have operating systems like VMS, BSD and OS/400 to name a few.
As for exploits, the level of user social engineering exploits is exploding with the growth of Linux, since most new users come from operating systems with poor security.
In my opinion Mac OS is hurting itself by making inexplicable security choices, causing pain where none is required, resulting in people actively disabling security to their own detriment.
As for actual exploits, they're getting more and more ubiquitous since more and more operating systems are running the same code, think python, nginx, bash, etc.
Finally, I'd point out that your attempt at dispelling what you call a myth does not appear to be backed up by facts or sources.
I've been in this industry for over 40 years and while it's far from perfect, I am comfortable stating that Linux is more secure than many operating systems and I suspect that it will continue to be the case for the foreseeable future.
I also note that it has a significantly larger user base than any other OS. Don't believe me? Heard of Android, same Linux kernel.
¹ There was a brief A/UX hybrid OS that had permissions, based on Unix System V and BSD. It was discontinued in 1995.
What exactly do you mean by "permissions" here? It sounds like you're just talking about basic Unix-style permissions. Also, what do you mean by "only the one based on BSD?"
Unless you're talking about Mac OS 9 and earlier (like more than 20 years old), all their OSes have permissions and are based on BSD at this point.
Standard Unix permissions also aren't gonna save you when you run an exploitable program as your home user and it can then access everything in your home directory (in other words, pretty much all of your important files for most users).
Just because AOSP uses many of the Linux kernels security features doesn't magically make other distros more secure. Same with servers vs desktop, which have far different usage requirements and patterns, and vastly different threat models.
Linux desktop is a decade or more behind the curve on exploit mitigations and harm reduction. Social engineering is still a security failure, and it almost as much the fault of OS developers that people are falling for these attacks.
Only recently has sandboxing become more popular for distributing applications, but it still isn't even close to as secure to AOSP or IOS/MacOS sandboxes. Flatpak and Snap are inherently insecure and that isn't even their fault because they aren't really meant to be secure sandboxes; they exist for easy system agnostic app distribution.
Many users still use X11 (or xwayland) which is consistently the source of vulns and regardless is massively insecure. X11 is a nasty rats nest of code and hacks which is massive, complex, and often runs privileged. Ever X11 app has complete access to the X server, and can: record the screen, read all window events and positions, record all keystrokes, send keyboard and mouse events, and much more. Wayland is a good step in the right direction. But Wayland compositors can also suffer from easy attacks, like using LD_PRELOAD to record keystrokes.
Speaking of LD_PRELOAD, most users have .bashrc writeable in there home. Any app that has write access to their home directory can preload a malicious binary which can modify and exploit the running app.
With .bashrc writeable, a hacker can just change tbe user's $PATH and create a fake sudo binary which records the user's password, and escalates to root without them knowing. Even specifying the full path isn't safe, because a hacker can just set an alias which takes priority of the actual path of the binary (eg. /usr/bin/sudo could be an alias of /tmp/sudo).
Now I hear you saying, why didn't the user just NOT run the malicious script or app? With supply chain attacks being at all time highs, you can't just rely on trusting your application developer. An app could get compromised and you wouldn't know. Even if you verify signatures, OpenPGP and GNUPG are inherently broken (see: gpg.fail, Latacora blog, Mathew Green blog)
Most distros use extremely weak memory allocators which allow for easy exploitation of memory corruption vulnerabilities. Hardened_malloc by GrapheneOS works on desktop Linux, with most apps just working fine out of the box. It helps to eliminate (or severely increase the complexity of) memory corruption vulnerabilities.
Many distros don't use mandatory access control policies like AppArmor or SELinux (eg. Arch Linux and its derivatives), and even if they do it isn't compare able to AOSP, like Fedora which use SELinux but doesnt by default isolate all applications with strong policies.
Then there are LTS distros, which because of their release schedule and also the way that CVEs are assigned, often miss important patches which go unnoticed (or not triaged for their security impact). See the recent copy.fail vuln which because of its disclosure timeline wasn't given ahead of time to distros. The only ones affected were slower moving distros, where as rolling release distros were fine (eg Arch Linux).
Of course let's not forget SETUID and SETGID which are the source of many many privilege escalation attacks, like in the case of that AppArmor vuln about a month ago. Daemon based privilege elevation tools (such as s6-sudo) avoid this problem, but they are not widespread. Systemd's run0 is a more popular example, but just like everything with systemd it is a massive attack surface and extremely complex under-the-hood.
Linux has many security modules (LSMs) such as MAC (eg. SELinux), Seccomp (for filtering syscalls), Landlock (for filesystem and network isolation), unprivileged user namespaces, etc. The only popular apps which make use of some of these features are browsers.
Of course drivers are another source of vulnerabilities because the are implemented in kernelspace instead of using a standardized ABI.
Linux is not a secure desktop OS. Neither is it very secure for a server OS (without extensive development of tools which properly use the kernels security features).
I could apply most of what I have said to the *BSDs within the context of Desktop OSes.
Excellent write-up! Thank you so much for this!
I'm typing this on Lemmy, not Mastodon.
@vk6flab How can I link my accounts or get it to show up on both?
if you mention a lemmy community in your post the post gets sent to show up in the lemmy community. Comments are automatically federated if you comment on a lemmy post.
lemmy posts are all federated to mastodon though if the servers know about each other
No idea. I have two accounts, one on Lemmy, one on Mastodon. Presumably somebody is mirroring this community to Mastodon, or perhaps the other way around, I'm not sure.
Lol.
Linux has vulnerabilities found because its a popular OS, so people actually vulnerability hunt on it. No one cares about freeBSD, so it doesn't get the same scrutiny.
This is also the same reason Windows has so many reported vulnerabilities, it is a massive target worth exploiting.
FreeBSD has cleaner code and a far simpler kernel. More eyes on the code doesn't make the code quality magically better, and vis versa. Linux has many security features not present in the *BSDs, but it also has a massive attack surface and has been historically hostile to security features (see: grsecurity isn't upstreamed because it was rejected by the kernel maintainers).
Cleaner code according to who?
I loathe that stupid anti-linux attitude from FreeBSD/OpenBSD (and sometimes even Haiku). Most of the time it just make them seem like crybabies, from Theo de Raadt going down: imagine being such a d-bag that even freaking Linus Tolvards calls you "a difficult person" - he says Linux folks do what they do "because they hate Microsoft" but they do what they do "because they love UNIX" but at the end of the day it seems they do what they do because they hate Linux.
They want to be more popular than Linux and their strategy is... to bitch about it instead of letting their own work speak for itself.
No OS is perfect. Not even self-proclaimed ultra-secure OpenBSD has been 100% free of vulnerabilities.
FreeBSD has recently faced significant vulnerabilities, including a 17-year-old remote code execution flaw in its NFS service
Meanwhile I basically see BSD as "another Linux".
Have you heard of the XZ backdoor attempt? I recommend to read it, to understand that its not easy to infiltrate Linux and why Linux is "not very vulnerable to exploits". FreeBSD is much smaller in scope than Linux for its code base and for developers working on it, and most stuff in the internet runs Linux. If a lot people would try to hack FreeBSD, then you would see a lot exploits too.
I agree with most of your points. But the *BSDs are not somehow more secure as a desktop OS. The suffer the same fundamental flaw which are present on Linux: no sane/coherent threat model. Desktop apps run unsandboxed without any MAC policies. The *BSDs also lack many of the useful security features available on Linux (not that most Linux distros do anything with that stuff either, except AOSP and ChromeOS). Just cus a kernel is more "secure" does mean anything when the stuff implemented in userspace doesn't make use of any of those features.
SELinux is very powerful, same with Seccomp and Landlock. But do any distros make extensive use of that and actually also sandbox applications.
FreeBSD has capsicum (and also an implementation of FLASK?, which is what SELinux is for Linux). OpenBSD has pledge. But are apps required to run in a isolated environment? Many of the *BSDs (and certainly .most of their users) still use X11 instead of modern alternatives like Wayland. The are still monolithic kernels which dont implement drivers in userspace, network, etc in userspace. Not secure at all.
MacOS is more secure, I agree. But it isn't trying nearly hard enough IMO.
Even if this is true in every sense, I cannot switch to any BSD system for my daily desktop usage.
It sounds like you’re just interested in pointing this security difference out, though. I suppose it’s good for folks running servers to be aware of this, since they can decide whether to use it or not, but for desktop usage, it’s unfortunately missing far too much software and far from simple to setup for an everyday user.
And that's why we should use hurd
I kind of agree. Linux needs some better security around packages and permissions. Like someone should work on an open-source snap alternative.
someone should work on an open-source snap alternative.
Is that not Flatpaks? They are damn good.
Flatpaks are not a secure sandbox. The sandbox exists to distribute apps, and the security is secondary. Apps are very minimally sandboxed. A better permission system would severely weaken the sandbox with basic permissions needed by so many apps. The amount of apps on Flathub that I have seen which need access to org.freedesktop.Flatpak which removes the sandbox. Browsers have their own sandbox crippled because Flatpak blocks namespace access, but that is not a problem for Snaps. Flatpak does not implement many (or any) modern exploit mitigations. Apps that have audio permission have microphone access, and access to all desktop audio. X11 access doesnt use something like Xephyr for a separate X11 to prevent apps from escaping the sandbox, especially on a X11 desktop environment. Etc, etc.
Now dont take me for a Snap shill. I don't think that is very good either. But at least its permission system is more thorough and apps tend to work better in a lot of cases. It also has on-screen permission requests (at least I think). It still suffers from many of the same problems as Flatpak.
I still use Flatpaks though. Just wish things were better.
Agreed, now if we can just get every program to run in a sandbox like flatpaks, a number of security issues will no longer be on issue.
The issue is not packaging, it's users circumventing security out of ignorance, willful or not, still ignorance.
As Linux gains popularity, the users will need to learn, often the hard way, how to go about installing stuff. Running a random script off the internet is not how it's done.