Linux 7.0 Could Bring a Major AppArmor Overhaul — Here’s What Kernel Developers Are Planning

The Linux kernel’s security infrastructure is about to undergo one of its most significant transformations in years. AppArmor, the mandatory access control framework that has quietly safeguarded Ubuntu and other major distributions for over a decade, is being lined up for a sweeping set of changes that kernel maintainer John Johansen hopes to land in Linux 7.0 — a release that could arrive as early as mid-2025 depending on Linus Torvalds’s versioning decisions.

The planned overhaul, first reported by Phoronix, centers on a substantial pull request that Johansen has been assembling for the next major kernel cycle. The scope of the changes goes well beyond typical incremental maintenance patches, touching the core architecture of how AppArmor manages policy, handles permissions, and interfaces with the broader Linux Security Module (LSM) framework.

A Long-Overdue Modernization of AppArmor’s Internals

AppArmor has long occupied a peculiar position in the Linux security hierarchy. While SELinux, developed originally by the National Security Agency, has been the default mandatory access control system for Red Hat Enterprise Linux and Fedora, AppArmor has served as the preferred alternative for Canonical’s Ubuntu, SUSE Linux Enterprise, and several other distributions. Its appeal has always been its relative simplicity — profiles are path-based rather than label-based, making them easier to write and audit for system administrators who lack deep security engineering backgrounds.

Yet that simplicity has come at a cost. AppArmor’s internal codebase has accumulated technical debt over the years, and several features that were planned or partially implemented have remained in limbo. The Linux 7.0 target represents an effort to address many of these long-standing issues in a single coordinated push, rather than trickling changes across multiple kernel releases where they risk introducing regressions piecemeal.

What the Pull Request Actually Contains

According to the details shared by Johansen and reported by Phoronix, the changes span several major areas. Among the most notable is a reworking of how AppArmor handles its permission model. The current permission system has been described by developers as rigid and difficult to extend, which has limited the framework’s ability to keep pace with newer kernel features and system call interfaces that require more granular access controls.

The planned updates introduce a more flexible permission architecture that should allow AppArmor to express finer-grained policies. This is particularly relevant as Linux continues to expand its support for features like user namespaces, io_uring, and eBPF — all of which have introduced new attack surfaces that existing AppArmor policies struggle to address comprehensively. The rework aims to make it possible to write policies that can govern these newer kernel subsystems without requiring awkward workarounds or overly broad allow rules.

Prompt and Notification System Changes

Another significant component of the planned changes involves AppArmor’s prompt and notification mechanisms. These systems allow AppArmor to interact with userspace when a policy decision needs human input or when security events need to be communicated to monitoring tools. The current implementation has been limited in scope and reliability, and the rework aims to bring it closer to what enterprise security teams expect from a production-grade mandatory access control system.

The notification improvements are particularly relevant for desktop Linux use cases, where AppArmor prompts could theoretically function in a manner similar to the permission dialogs familiar to macOS and Android users. Canonical has expressed interest in this direction for Ubuntu, and a more capable notification subsystem in AppArmor would be a prerequisite for that kind of user-facing security model. The changes Johansen is proposing would lay the groundwork for such features, even if the full user experience work would happen in userspace tooling rather than the kernel itself.

Policy Compilation and Loading Efficiency

The pull request also addresses performance concerns around policy compilation and loading. As AppArmor profiles have grown more complex — particularly in containerized environments where hundreds or thousands of profiles might be active simultaneously — the overhead of compiling and loading those profiles has become a measurable concern. The changes include optimizations to the internal data structures that AppArmor uses to represent and evaluate policies, which should reduce both memory consumption and the time required to load new profiles at runtime.

This matters enormously for container orchestration platforms like Kubernetes, where pods are frequently created and destroyed, each potentially carrying its own AppArmor profile. Docker and containerd have long supported AppArmor profiles for container isolation, and any improvement in profile loading performance translates directly into faster container startup times and reduced overhead on the host system. For cloud providers running thousands of containers per node, even small improvements in this area can have meaningful aggregate effects.

The Linux 7.0 Versioning Question

The targeting of Linux 7.0 for these changes raises an interesting question about kernel versioning itself. Linus Torvalds has historically been somewhat whimsical about when to bump the major version number. Linux 6.0 arrived in October 2022, not because of any particular technical milestone, but because Torvalds felt the minor version numbers were getting unwieldy. If he follows a similar pattern, Linux 7.0 could arrive once the 6.x series reaches a sufficiently high minor number — possibly around 6.14 or 6.15, which would place the transition sometime in mid-to-late 2025.

This means the AppArmor changes, while targeted at a major version number, are not necessarily far off. Johansen’s decision to aim for 7.0 likely reflects both the scope of the changes — which benefit from landing together rather than being split across releases — and the practical reality that large security subsystem reworks require extensive review and testing that aligns better with a major release cycle.

Implications for Ubuntu and Other Distributions

For Canonical, which has been AppArmor’s most prominent corporate backer, these changes are directly relevant to the company’s roadmap. Ubuntu 25.10, expected in October 2025, could potentially ship with a kernel that includes the new AppArmor code, depending on timing. More importantly, Ubuntu 26.04 LTS — the next long-term support release — would almost certainly incorporate these improvements, making them available to the vast installed base of Ubuntu servers and desktops that rely on LTS releases for stability.

SUSE, the other major distribution that ships AppArmor by default, would similarly benefit. SUSE Linux Enterprise Server (SLES) and openSUSE Tumbleweed both depend on AppArmor for their default security posture, and the improvements to permission handling and policy loading would address pain points that enterprise customers have reported for years.

The Broader Linux Security Module Picture

The AppArmor rework also arrives at a time when the Linux Security Module framework itself is undergoing significant evolution. Recent kernel releases have introduced the ability to stack multiple LSMs — running AppArmor and another security module simultaneously, for example — which has required changes to how individual LSMs interact with the kernel’s security hooks. The AppArmor changes for Linux 7.0 take this stacking capability into account, ensuring that the reworked code plays well with other security modules rather than assuming it has exclusive control over security decisions.

Additionally, the growing interest in eBPF-based security tools like Cilium’s Tetragon and the BPF LSM has created a new dynamic in Linux security. While these tools operate differently from traditional LSMs like AppArmor and SELinux, they compete for mindshare among security engineers, and the AppArmor maintainers appear to be responding by ensuring their framework remains capable and relevant in environments where multiple security enforcement mechanisms coexist.

What Comes Next for Kernel Security

The Linux 7.0 AppArmor changes represent one of the larger single-cycle security subsystem updates in recent kernel history. If the pull request is accepted in its current form — and given Johansen’s track record as AppArmor maintainer, there is reasonable expectation that it will be, after the usual review process — it would mark a significant maturation point for the framework.

For system administrators, security engineers, and distribution maintainers who depend on AppArmor, the practical advice is straightforward: begin reviewing the proposed changes now, test against development kernels when they become available, and plan for policy updates that take advantage of the new permission model. The transition should be backward-compatible for existing profiles, but the new capabilities will only be accessible through updated policy syntax and tooling. As with any major kernel subsystem change, early testing in staging environments will be essential to a smooth production rollout.