AppArmor Issues on EndeavourOS (Standard and LTS Kernels) - Seeking Community Input

Hello EndeavourOS community,

I’ve been trying to enable AppArmor on my system to enhance security. I’m running EndeavourOS with two kernels installed: the standard linux kernel (currently 6.14.4-arch1-2) and the LTS kernel (linux-lts 6.12.26-1).

After installing the apparmor userspace tools, I’ve encountered a persistent issue where the AppArmor filesystem (securityfs) does not appear to be mounted. This is preventing the apparmor.service from starting, as it fails the ConditionSecurity=apparmor check.

Here’s a summary of the troubleshooting steps I’ve taken, with the assistance of online documentation and AI support:

  • aa-status consistently reports “apparmor filesystem is not mounted.”
  • Manually attempting to mount securityfs using sudo mount -t securityfs ... did not result in a persistent mount.
  • Adding securityfs /sys/kernel/security securityfs defaults 0 0 to /etc/fstab did not automatically mount it on reboot.
  • Checking the status of the apparmor.service with systemctl status apparmor.service shows it as inactive (dead) with the condition “ConditionSecurity=apparmor was not met.”
  • Crucially, I’ve been unable to find the apparmor kernel module (.ko.xz file) in the expected location (/lib/modules/$(uname -r)/kernel/security/) for both the standard and LTS kernels. A search using sudo find /lib/modules/$(uname -r)/ -name "apparmor*" only reveals build directories and header files, not the loadable module.
  • This lack of a kernel module seems to contradict the Arch Wiki’s statement that “AppArmor is available in all officially supported kernels.”

Given these findings, I have a few questions for the community:

  1. Has anyone else experienced issues with AppArmor on the current EndeavourOS standard and LTS kernels?
  2. Is the apparmor kernel module expected to be present in these kernels? If so, could someone point me to its location?
  3. Are there any specific steps or configurations unique to EndeavourOS that are required to enable AppArmor?
  4. Are there alternative kernels within the EndeavourOS/Arch ecosystem where AppArmor is known to be working correctly?

Any insights or suggestions would be greatly appreciated. It seems like there might be an issue with the inclusion or availability of the AppArmor kernel module in the current kernel packages.

Thank you for your time and assistance.

I have followed the instruction in Archwiki: https://wiki.archlinux.org/title/AppArmor


$ systemctl status apparmor.service 
● apparmor.service - Load AppArmor profiles
     Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; preset: disabled)
     Active: active (exited) since Sat 2025-05-03 22:45:43 CEST; 38min ago
 Invocation: ac4f163ac3d34f448d449
       Docs: man:apparmor(7)
             https://gitlab.com/apparmor/apparmor/wikis/home/
    Process: 415 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS)
   Main PID: 415 (code=exited, status=0/SUCCESS)
   Mem peak: 216.7M
        CPU: 13.689s

I don’t see any mention of securityfs in that page. What guide/tutorial have you been using?

I used the same page plus several hours of Gemini AI help to debug my install. The summary of which I posted in this OP

You can Open a terminal and run:
Bash

sudo aa-status

If you see profiles listed in enforce mode and processes associated with them, that’s a good sign AppArmor is actively working.

Test with a confined application (if you know one): If you know of an application on your system that has an AppArmor profile (you might see its name listed in aa-status), you could try to perform an action with that application that you suspect might be restricted by its profile. Then, check dmesg again to see if there’s an “apparmor=” entry with “operation=…” and “denied=1”.

For example, if a web browser is confined, you might try to access a system file outside of its allowed directories and see if AppArmor logs a denial. Be careful when doing this, as you might trigger unexpected behavior in the application.

Check the AppArmor profile for a specific application: You can examine the AppArmor profile for an application (usually located in /etc/apparmor.d/) to understand what restrictions are in place. While this doesn’t tell you if it’s actively working, it gives you context on what it should be doing.

Well, that is strange then that it is not working for you.

I have not needed to add anything to /etc/fstab and yet:

$ mount | grep securityfs
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)

Can you post: cat /proc/cmdline ?

Also:

zgrep -i apparmor /proc/config.gz

zgrep -i securityfs /proc/config.gz

Which profiles do you have activated as I have read that most apparmor profiles are written for Ubuntu-based distributions, so not sure that would benefit Arch Linux?

I have https://aur.archlinux.org/packages/apparmor.d-git

# aa-status 
apparmor module is loaded.
1840 profiles are loaded.

Most of them are in complain mode though.

1 Like

Why not switch them to enforce mode if they are profiles for Arch Linux?

Yes. Good question! I haven’t tried.

1 Like

Besides installing that PKGBUILD did you have to copy those profiles to a /etc/apparmor.d for them to be loaded, just asking as I might try it myself since I didn’t know about those Arch specific profiles before?

No. It installs them there when you install it from AUR.

They may not be only specific to Arch though:

1 Like

Hello,
I guess you can get some info from the system log :

journalctl -b0 -r | grep apparmor

I tried it out but it looks like of everything that’s in enforcing mode is either not valid for Arch Linux or not installed and when you try to load everything into enforcing mode it finds conflicting profiles meaning you are going to have to sort out manually which profiles you want to enable. So not sure if it actually adds value on Arch Linux, at least not for me if I am going to have to manually select which profiles I want to put into enforcing mode because I am not going through 1800 profiles.

1 Like

I think also that this is the way it needs to be handled. On a per case basis. Certainly a tedious work.