Linux Security

Linux security has always been a sensitive subject in the industry, and this article will no doubt start some fires.

Before diving into the security practices of the OS, let’s make one thing clear, Linux runs our modern world - ChromeOS, Android phones and TVs, cars, fridges, smart devices. It’s an amazing operating system and we should all appreciate it for that. Due to the widespread use of Linux, it is one of the most mission-critical pieces of software to ever exist, and as such should be held to extremely high security standards.

This article is not meant to cause any wars, nor is it meant to call out any individual developers of the operating system. The industry widely accepts that Linux security is fundamentally flawed and needs a serious overhaul to provide the security necessary in today’s world. Hopefully, this article will inform both those that are experienced with Linux, and those with very little. The hope is to encourage Linux security to be better.

To prevent conflict, as with all other articles on this website, sources will frequently be referenced for all information presented.

Lack of Verified boot

To have verified boot, an OS needs to have a seperate system volume that is signed by the OS vendor. The Firmware then makes sure that the volume has the correct signature. For that to be possible, the OS has to be fully immutable. There is currently no Linux Distribution that achieves this. “Immutable” Distributions such as Silverblue aren’t fully immutable.¹ Fedora is currently working on a way to fix this by introducing proper UKI support.² For the same reason Secureboot isn’t properly implemented yet either.

Application Sandboxing

Linux has lackluster application sandboxing. There are currently only two package formats that support it even partially, namely Flatpak, the verified remote of which is used by default in Secureblue and Canoncial’s Snap, which is included by default in Ubuntu. For both, Applications decide what permissions they get by default, meaning if a permission is revoked, the app cannot grant it to itself. Similairly to how it works on Android, although Android’s implementation, which grants apps permissions directly by the user at runtime is better. However, they don’t come without issues. While a user can deny any permission to an application, many developers do not accomodate for this, which results in crashes or other unexcpected behaviour. Additionally, both package formats grant access to x11 by default. Flatpak specifially has issues, as it breaks Browser Sandboxing, therefore using flatpak versions of browsers isn’t recommended.³

The Distribution Fracturing Problem

The Linux developer ecosystem is unique in many ways, with a culture and practices that differ from every other operating system. This creates a beautiful yet scary environment for reasons we’ll discuss in the sections below.

Stable Release

A large amount of distributions such as Ubuntu, Debian, RHEL, Rocky Linux, Oracle Linux, and CentOS are categorized as “stable release” Linux distributions and always use the long-term support (LTS) kernel. Stable release Linux distributions use outdated packages, only ever backporting security fixes when a CVE has been reported. While this sounds good in practice, a large amount of security vulnerabilities never get assigned a CVE, and as such are never backported to a stable release distribution.

Additionally, backports are not always a proper fix as claimed. There are many different examples of backports taking 6-12 months, and many more examples of backports either introducing a new vulnerability, or breaking something.

Research from Chainguard in 2024 analyzed over 600 open source projects which contained over 100 security fixes that were never assigned a CVE.

A study from Springer in 2022 found that 37.19% of Linux kernel vulnerabilities never use terminology in the commit log to imply a security fix. Furthermore, this study shows that 147,746 commits contained the words “bug”, “vuln”, or “fix”, of which only 986 were for known CVEs. It should be noted however that the exact number of commits in this dataset that correlated to fixing a vulnerability is unknown.

A study from North Carolina state university in 2023 created a dataset of the 1000 latest commits in the NPM, Python, Go, PyPI, and Maven projects. They found that 52.86% of projects silently fixed vulnerabilities.

While two of the studies cited do not specifically cover the Linux kernel, they highlight the fact that CVEs are not properly disclosed or reported within the open source community. This is particularly important because of the nature of Linux. Linux is not just a kernel; it’s also the set of packages that ship with the kernel in each Linux distribution.

Debian hosts a security tracker which shows a very large number of vulnerable packages with CVEs that have not yet received a fix.

Ubuntu has a whole blog post explaining how they fix security problems within the distribution and its packages. They have maintainers manually check the CVE databases to see if packages within Ubuntu are vulnerable, and then manually backport each fix.

Rolling Release

Rolling release distributions tend to use the stable kernel and includes distributions such as Arch Linux. Due to using the mainline kernel, all vulnerabilities are patched even if there is no published CVE, unlike with stable releases.

The core Linux developers claim is that everyone should be using the latest version of the Linux kernel as that’s the only way to ensure you have all the latest fixes, vulnerability or not. However, this claim falls apart due to the lack of developer standards within the Linux kernel. The Linux kernel allows for new features and bug fixes to be merged without tests or fuzzing. To make matters worse, the code coverage of the Linux kernel is currently unknown. This lack of developer standards has created a culture that allows for new features and bug fixes to be merged without testing or fuzzing, which themselves may introduce new vulnerabilities or be poorly documented.

In an attempt to address some of these issues, Google has been fuzzing the Linux kernel for years, foundations such as the OpenSSF (Open Source Security Foundation) have been created, and various companies like Microsoft have begun paying employees to work full-time on securing the Linux kernel.

Stable Release vs Rolling Release

So if stable releases do not contain all vulnerability fixes from upstream, but rolling releases contain all vulnerability fixes alongside new unknown vulnerabilities, what is the best approach? It’s really a damned if you do and damned if you don’t situation, regardless of which option you choose.

Google has an entire blog post about Linux kernel security done right which explains that if you are not using the latest stable kernel, you’re leaving yourself vulnerable. Their conclusion is the same as what is mentioned above in the stable release section; developers should focus their efforts on upstream contributions to increase overall efficiency of bug fixes, reduce time to patching, and reduce the sheer amount of redundant work being done on each distribution backporting their own fixes.

One solution that is used in Android is tracking the upstream stable kernel releases, but discarding all the new features. This creates a balance of receiving all the latest vulnerability fixes while also ensuring unnecessary new features and attack surface are not being introduced. Unfortunately, no Linux distributions appear to be taking this approach at the time of writing.

Duplicated Efforts

At the time of writing, there are 6 LTS kernels and 1 stable kernel according to kernel.org. However, kernel.org does not list every Linux kernel that exists.

Lots of distributions such as Ubuntu maintain their own forks of the Linux kernel with their own modifications and changes.

Each distribution compiles the kernel differently and may apply its own patches on top. This leads to situations where multiple Linux distributions may be running the same kernel version, but each kernel enables/disables different features of the kernel, applies its own patches, uses its own security policies, and maintains its own backported security fixes.

This process creates a lot of unnecessary duplicated effort within the Linux community. In an ideal world, all distributions would contribute upstream so that all Linux users would benefit, but unfortunately this is not the case.

Exploit mitigations

Similarly to how a lot of distributions maintain their own kernel, the same is true for exploit mitigations. Fedora and Ubuntu stand out as having some of the best exploit mitigations. See Fedora’s security docs and Ubuntu’s security docs for the latest exploit mitigations in place for both distributions.

Secureblue is a community project based on Fedora which adds additional hardening to the system. See Secureblue’s GitHub for additional information on the project.

Ubuntu also has a list of mitigations they apply, including using intel’s CFI, which is an important exploit mitigation, even if not as extensive as hardened_malloc. However The Problems with backporting and outdated packages described prior still stand.

Secureblue has a couple mitigations that are unique to it. The project comes with hardened_malloc preinstalled by default for both rpms and flatpaks. The project even goes as far as having it’s hardened-chromium subproject, which is inspired by Vanadium and uses Fedora’s Chromium as a base. The project only recommends the use of Gnome images, as it is the only DE that prevents apps from accessing screen content at the time of writing, KDE has plans to implement it, but hasn’t done so yet.⁴ The project constantly tries to remove unnecessary attack surface if possible, this general mentality works very well for exploit mitigations and is what GrapheneOS describes as the first step defending against unkown vulnerabilities.⁵ The Project also has globally disabled User namespaces by default, which allow unpriveleged users to interact with parts of the Kernel which are reserved for root, this is cause for many attack vectors using privelege escalation. Disabling this feature breaks functionality like Toolbox and means flatpak can’t function without suid set to the bubblewrap binary, therefore bubblewrap creates namespaces instead of the user, in other words it runs as root. As the Project puts it:

you might think we should just disable this functionality altogether. However if this functionality is disabled globally, then flatpak can’t function. To mitigate this, we first revoke user_namespace privileges from the unconfined domain in our selinux policy. Then, we confine flatpak and grant it user_namespace privileges. We do the same for hardened-chromium. This allows them to create user namespaces while keeping them globally disabled by default. We don’t do this for bwrap or podman directly because the syscall filters for both are weak by default. If you need container domain userns (e.g. for distrobox), you can enable it with ujust toggle-container-domain-userns-creation. If you need to use any other software that requires user namespace creation privileges (e.g. bubblejail), you can enable it with ujust toggle-unconfined-domain-userns-creation. But keep in mind that this is a security degradation.

Canonical considers user namespaces to be a substantial risk, too, and has restricted them via a global AppArmor policy since 23.10 by opt-in and since 24.04 by default.

Source