Linux Security Features You Should Never Disable

Almost every Linux admin has done it. An app refuses to start, a container can’t reach a socket, and a forum post says, “Just turn off SELinux.” Five seconds later the error is gone and the problem feels solved.

It usually isn’t. You’ve traded one visible error for a hole you can’t see.

This guide covers the Linux security features you should never disable, why each one matters, and what to do when one of them gets in your way. The context is current: Linux 7.3 shipped on October 18, 2026, and the numbers behind kernel security have changed a lot this year.

Linux 7.3 was a record-setting release, with 18,765 non-merge commits from 3,021 developers, 807 of them first-timers. More code and more eyes mean more fixes, and more reasons to keep your defenses switched on.

---

Why This Matters More in 2026

Kernel vulnerability reporting has changed sharply, and it affects how you should think about hardening.

According to Phoronix’s report on Greg Kroah-Hartman’s Kernel Recipes 2026 slide, the kernel averaged around 500 fixed CVEs per release from Linux 6.9 through 6.19. Since 7.0 the figure has passed one thousand, and 7.2 went beyond 1,500. By early September 2026 it was approaching 2,000, and 7.3 could be the first release to cross that line.

Before you panic, there’s context. As Tom’s Hardware explains, the jump is driven mainly by people using AI tools to scan a kernel source tree of more than 40 million lines, rather than by Linux suddenly becoming less secure. Many of the newly found bugs are low priority and sit in old drivers or rarely used code.

Still, the practical lesson is clear. Attackers can run the same scanning tools cheaply and at scale. The time between a bug being found and someone trying to exploit it keeps shrinking. That makes your layered defenses the thing standing between a bug and a breach.

A quick personal note: after years of cleaning up servers where someone “temporarily” disabled a control, I can tell you the temporary part almost never happens. Treat every disabled protection as permanent unless you’ve scheduled its return.

---

Quick Comparison: The Features at a Glance

Feature	What it protects against	Typical performance cost	Risk if disabled	Verdict
SELinux / AppArmor	Compromised apps reaching files and processes they shouldn’t	Low	High	Never disable
Firewall (nftables, firewalld, ufw)	Unwanted inbound network access	Negligible	High	Never disable
Automatic security updates / livepatch	Known, already-patched vulnerabilities	None	Very high	Never disable
Secure Boot	Tampered bootloaders and unsigned kernel code	None at runtime	Medium to high	Keep on if hardware allows
Full-disk encryption (LUKS / TPM-backed)	Data theft from lost or stolen devices	Low on modern CPUs	High on laptops	Never disable on portable devices
ASLR and kernel hardening	Reliable memory-corruption exploits	Very low	High	Never disable
CPU vulnerability mitigations	Spectre-class side-channel leaks	Low to noticeable (workload-dependent)	Medium	Disable only with a documented reason
SSH key auth and root-login restrictions	Brute-force and credential attacks	None	Very high	Never weaken
Auditing (auditd / journald)	Blind spots during incident response	Low	Medium	Keep on
sudo and least privilege	Full-system compromise from one account	None	High	Never bypass

The sections below explain each one and what to do when it blocks you.

---

1. Mandatory Access Control: SELinux and AppArmor

This is the feature most people switch off, and the one I’d defend hardest.

Standard Linux permissions answer one question: does this user own this file? Mandatory access control asks a harder one: should this program touch this file at all? A web server has no business reading SSH keys, even if it technically runs as a user who could.

SELinux vs AppArmor

• SELinux (Fedora, RHEL, Rocky, AlmaLinux) labels everything and enforces detailed policy. It’s very powerful but has a steeper learning curve.
• AppArmor (Ubuntu, Debian, openSUSE) uses path-based profiles. It’s easier to read and write, with somewhat coarser control.

AppArmor is still doing heavy lifting in 2026. On Ubuntu it is the default security module and enforces profiles for every snap and system service, and Mondoo’s security review of Ubuntu 26.04 notes that the new LTS added fresh kernel-side hooks for it. Ubuntu 26.04 LTS also added AppArmor enforcement for OpenLDAP.

What to do instead of disabling it

1. Switch to permissive mode temporarily (setenforce 0 on SELinux) so you can see what would be blocked.
2. Read the denial logs (ausearch -m avc, or journalctl for AppArmor).
3. Generate a targeted rule or set the correct boolean or label.
4. Return to enforcing mode.

Most “SELinux broke my app” cases turn out to be a wrong file context or one missing boolean. It’s a two-minute fix once you look at the log.

---

2. The Firewall

A firewall that’s “off while we test” is the most common way services end up exposed to the whole internet. Databases, admin panels and debug ports all get found by scanners within hours.

Modern Linux gives you several friendly front ends over nftables:

• ufw for simple host rules on Ubuntu and Debian
• firewalld for zone-based setups on RHEL-family systems
• Raw nftables for fine control and servers with complex rules

Keep a default-deny inbound policy and open only what you need. If something can’t connect, add a specific rule for that port and source rather than turning the whole thing off.

On cloud servers, don’t assume the provider’s security group is enough. Host firewalls and cloud rules protect you at different layers, and having both saves you when one is misconfigured.

---

3. Automatic Security Updates and Livepatching

If I had to pick one control that prevents the most real-world breaches, it’s patching. Most compromised servers weren’t hit by exotic zero-days. They were running software with a fix that had been available for weeks.

With CVE volumes rising, manual patching on a “when I remember” schedule no longer works.

What to enable:

• unattended-upgrades on Debian and Ubuntu
• dnf-automatic on Fedora and RHEL-family systems
• Kernel livepatching where your distro supports it, so critical kernel fixes apply without a reboot

For long-lived systems, support length matters too. Canonical says security coverage, hardening and kernel livepatching for Ubuntu 26.04 LTS can extend up to 12 years through Ubuntu Pro. Even if you never buy it, know your distro’s support window so you’re never running an end-of-life system.

One caution on kernels: fixed-release distributions usually backport fixes rather than jump to the newest kernel. Rolling distributions like Arch Linux, openSUSE Tumbleweed and CachyOS adopt new stable kernels quickly, while fixed-release distributions backport the relevant fixes. So don’t judge your safety by the version number alone. Check your distro’s security tracker, and use the official Linux Kernel Archives to see which stable and longterm branches are currently maintained upstream.

---

4. Secure Boot

Secure Boot checks that the bootloader and kernel are signed before they run. It stops a class of attacks that live below the operating system, such as bootkits that load before your defenses wake up.

Linux support is solid, and the reasons people disable it have mostly disappeared. Disabling it usually comes from:

• Third-party kernel modules (NVIDIA drivers, VirtualBox)
• Custom kernels
• Older guides that said “turn it off first”

Better options: enroll a Machine Owner Key (MOK) so you can sign your own modules, or use your distro’s signed packages. Both keep Secure Boot enabled while still letting you run what you need.

Be honest about its limits. Secure Boot doesn’t protect a running system from a compromised app. It’s one layer, not a complete answer. But removing it for convenience gives up protection that costs nothing at runtime.

---

5. Full-Disk Encryption

Encryption at rest is the difference between “I lost my laptop” and “I had a data breach.” On a laptop, never skip it.

Ubuntu 26.04 LTS moved TPM-backed full-disk encryption from experimental to production-ready, and lets you set or remove a PIN after installation or re-encrypt a disk from the Security Center without reinstalling. Storing the key in the TPM also means you no longer type an unlock password at boot.

TPM-only vs TPM + PIN

Setup	Convenience	Protection level
Passphrase only (classic LUKS)	Type at every boot	Strong, depends on passphrase quality
TPM-only unlock	Seamless boot	Good against casual theft, weaker if an attacker has physical time with the device
TPM + PIN	One short PIN at boot	Best balance for most laptops

For a desktop that never leaves a locked room, TPM-only is reasonable. For anything that travels, add the PIN.

Modern CPUs have hardware AES acceleration, so the performance penalty is small enough that “it’s slower” is no longer a good reason to skip encryption.

---

6. Memory Protections and Kernel Hardening

These are the quiet defenses you never see: ASLR (randomized memory layout), NX/DEP (non-executable memory), stack protectors, and kernel-level options like stack erasing.

They exist for one purpose: to turn a memory bug that could become full code execution into one that just crashes. That’s a huge difference for defenders.

The common mistake is flipping kernel.randomize_va_space to 0 for debugging and forgetting to revert it. Check it:

cat /proc/sys/kernel/randomize_va_space

You want 2.

Distros are also pushing memory safety further down the stack. Ubuntu 26.04 replaced sudo with the Rust-based sudo-rs and adopted Rust-based core utilities. Note that cp, mv and rm still use GNU versions for now because of unresolved race-condition bugs. If you replace or pin those tools back to old versions without a reason, you’re undoing deliberate safety work.

---

7. CPU Vulnerability Mitigations (The Honest Gray Area)

This is the one place I won’t say “never.” Boot options like mitigations=off can recover real performance on certain workloads, and the cost is hard to generalize because it depends on the CPU and the task.

My rule of thumb:

• Multi-user systems, shared hosts, anything running untrusted code (containers, VMs, browsers): keep mitigations on.
• Isolated single-purpose compute boxes with no untrusted code and no network exposure: disabling can be defensible, but write down why.

Newer kernels are also giving admins finer control. Ubuntu 26.04’s kernel brought Attack Vector Controls, which add a management layer over CPU vulnerability mitigations. That lets you tune protections by threat scenario instead of using a blunt on/off switch. Use that before reaching for mitigations=off.

---

8. SSH Hardening

Exposed SSH is one of the most attacked services on the internet. Within minutes of a new server getting a public IP, login attempts begin.

Keep these on:

• Key-based authentication (disable password login when practical)
• PermitRootLogin no (or prohibit-password at minimum)
• Rate limiting or a tool like fail2ban
• Current OpenSSH versions

There’s also a forward-looking reason to stay current. Ubuntu 26.04 LTS ships OpenSSH 10.2 with a hybrid post-quantum key exchange (mlkem768x25519) by default. That protects today’s traffic against “harvest now, decrypt later” collection. Pinning an ancient SSH client or server to dodge a compatibility error throws that away.

Note that OpenSSH 10.0 removed DSA support, so very old keys may fail. Generate an Ed25519 key instead of re-enabling legacy algorithms.

---

9. Auditing and Logging

Logs are boring until the day you need them. Disabling auditd or log retention to save disk space feels harmless, and then an incident happens and you can’t answer “what changed, and when?”

Keep:

• journald persistent storage on servers
• auditd rules for logins, privilege escalation and changes to sensitive files
• Log forwarding to a separate machine, because attackers delete local logs first

Disk is cheap. Not knowing what happened is expensive.

---

10. sudo and Least Privilege

Running everything as root, adding NOPASSWD: ALL for convenience, or making configuration files world-writable are the habits that turn a minor flaw into a full takeover.

Better habits:

• Give users the narrowest sudoers rules that work
• Use service accounts for daemons
• Prefer sudo -e and per-command rules over root shells
• Review /etc/sudoers.d/ occasionally

Modern services are moving the same way. In Ubuntu 26.04, the SSSD identity service no longer runs as root. The industry direction is clear: fewer things running with full privilege.

---

Pros and Cons of Keeping the Full Security Stack Enabled

Pros

• Each layer catches what the others miss, so one flaw rarely becomes a full compromise
• Many defenses cost almost nothing at runtime on current hardware
• Easier compliance and audit conversations
• Faster recovery, because logs and confinement limit the damage

Cons

• Initial setup takes learning time, especially SELinux policy
• Some third-party software and out-of-tree drivers need extra steps (module signing, custom profiles)
• A few mitigations carry workload-specific performance costs
• Misconfigured controls can cause confusing failures that tempt people to give up

The cons are mostly about effort, not risk. That’s the right trade.

---

A Practical Troubleshooting Mindset

When a security feature blocks something, follow this order instead of disabling it:

1. Confirm it’s the cause. Use permissive mode or logs, not guesswork.
2. Read the denial. The message usually names the exact file, port or action.
3. Make the smallest change. One rule, one label, one boolean.
4. Test, then re-enable enforcement.
5. Document it. Future you will forget why that rule exists.

If you truly must disable something, set a calendar reminder and scope it as narrowly as possible, such as a single service or a single test host.

---

A Sensible Baseline Checklist for 2026

• SELinux or AppArmor in enforcing mode
• Default-deny firewall with only required ports open
• Automatic security updates enabled; supported OS version in use
• Secure Boot on (with MOK signing for custom modules)
• Disk encryption on every portable device, ideally TPM + PIN
• ASLR value at 2
• SSH keys only, no direct root login
• Persistent logs and basic audit rules
• Least-privilege sudoers

---

FAQ

---

Conclusion

Security features rarely feel valuable on the day they’re working, which is exactly why they get switched off. But the Linux security features you should never disable (mandatory access control, the firewall, automatic updates, disk encryption, memory protections and SSH hardening) form the stack that keeps one mistake from becoming a breach.

With kernel fix volumes climbing toward 2,000 per release and attackers using the same automated tools as defenders, the safest habit is also the simplest: when something breaks, investigate the control instead of removing it. Fix the rule, not the wall.

---

Disclaimer: This article is for general information and educational purposes only. Security needs vary by environment, so test configuration changes in a safe setup first and consult your distribution’s official documentation or a qualified security professional before making changes to production systems. Version numbers and release details reflect information available in October 2026 and may change.

---