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:
Has anyone else experienced issues with AppArmor on the current EndeavourOS standard and LTS kernels?
Is the apparmor kernel module expected to be present in these kernels? If so, could someone point me to its location?
Are there any specific steps or configurations unique to EndeavourOS that are required to enable AppArmor?
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.
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.
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?
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?
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.
After a bit of hunting around I suspect a more generalized solution might be to use the arch hardened kernel on EOS… I’ll test and see what I unearth. Either way I think the 90+% solution works; a few complains and even the odd warnings aren’t fatal to anything, so far as I have noticed. I’ll get around to writing up a tutorial on what seems to work for me (for any who are interested). As for tedious… yep. Is it worth it? I think so… but I’m not allowed to explain why, on these forums.
I don’t have a problem with anyone explaining something. I didn’t find Apparmor useful if I have to select one by one which Apparmor profile I want on enforcing, especially if there are two profiles for different things in the same directory. From the ones I saw even the one from that git repo most things don’t apply to Arch or you need something specifically installed from a different profiles which is from the ones I checked not the case on my system. Then getting back to I don’t really want to have to manually select the ones I do want activated would rather just activate them all and let it do it’s work if the command or application is available on the system that is mentioned in a profile. I do prefer selinux and have tried getting it to work but found that’s even more manual work to setup on Arch so just left it for now.
