Skip to content

Frequently Asked Questions

This page contains answers to common operational questions regarding AppArmor.

Profile Management

Does editing/removing a file in /etc/apparmor.d/ update the loaded policy?

No. For the policy being enforced to be changed, it must be loaded into the kernel. The recommended way of doing this is:

sudo apparmor_parser -r /etc/apparmor.d/profile.file.name    # to r a single profile

The modified profile will be applied the next time the application is started.

With that being said, if you modify a profile from logprof or genprof, the tool will reload the profile for you.

It is also possible to remove a profile using:

sudo apparmor_parser -R /etc/apparmor.d/profile.file.name    # to REMOVE a single profile

Can I change the policy of a running application?

Yes, but only if the application is already confined.

This is called Profile Replacement. You can replace a currently loaded profile with a new version of the same profile (e.g., using sudo apparmor_parser -r /etc/apparmor.d/profile). When you do this: - The running application immediately begins using the new profile for all subsequent access decisions. - The application retains access to any files or resources it already had open before the profile was replaced. - Any new child processes launched by the application will be subject to the new profile (depending on transition rules).

While profile replacement is convenient because it doesn't require restarting the service, the most secure solution is always to restart the application to ensure it hasn't cached any privileges or open files from the older profile.

Can I apply a profile to an unconfined running application?

No. You cannot apply brand new policy to a running process that is currently unconfined.

If an application is started before its profile is loaded into the kernel, or if its profile is removed while it is running, the application becomes unconfined. The Linux kernel's credential handling prevents attaching a new security context to an already running unconfined task.

To confine the application, you must load the policy into the kernel and then restart your application.

Why isn't removing and reloading a profile equivalent to profile replacement?

Because removing a profile (using apparmor_parser -R) strips the confinement information from the running task, making it unconfined. When you subsequently reload the profile, AppArmor cannot reattach it to the now-unconfined running application (as explained above). The application must be restarted to be confined again.

Where is AppArmor policy stored?

AppArmor system profile files and related files are traditionally stored in the directory /etc/apparmor.d/.

Can a profile file contain multiple profiles?

Yes. The convention is to break out profiles into multiple files, as this makes it easier for package management to add new profiles by just adding a file. However, there is no reason a profile file cannot contain multiple profiles, and this is even done in some cases where profiles are closely related.

How do I disable a profile?

Profiles can be disabled by either adding a symlink to the profile file in the /etc/apparmor.d/disable/ directory, or by removing the profile file from the /etc/apparmor.d/ directory.

Monitoring and Errors

I have an application that is unconfined but I have a profile for it. What can I do?

You must load the policy into the kernel, then restart your application. If an application is started before a profile is loaded or if a profile is removed after an application is started, the application will be unconfined.

I have an application that is not confined and aa-status does not report this correctly

A known limitation of aa-status is it will not report when an application for which a profile is loaded is running unconfined if the profile uses path name globbing to specify the application to be confined.

What causes "Failed name lookup" and how do I fix it?

Failed name lookups are caused when AppArmor tries to resolve the path name of a previously opened file object and fails. There are three distinct reasons this can happen:

Failed name lookup - deleted entry

The file has been marked for deletion and no longer has a valid name (for the referencing object) in the file system. When this happens AppArmor will do one of two things:

  • Implicitly delegate access to the file if there are no hard links (alternate names) to the file. This case will not cause Failed name lookup messages.
  • Attempt to revalidate by doing a name lookup which fails. For deleted files, AppArmor can mediate the file object via the pathname it would have had by passing the mediate_deleted flag on the profile:
 /example flags=(mediate_deleted) {
   # ...
 }

Failed name lookup - disconnected path

A file or object was accessed that has no connection to the filesystem root (or the current namespace's root). Common causes include: - A lazily unmounted device path was opened outside of the current namespace. - Accessing an abstract socket. - Accessing files that have no path representation (e.g. some deleted files or file="").

If needed this error can be bypassed using the attach_disconnected profile flag.

Failed name lookup - name too long

AppArmor has a maximum pathname size that can cause pathname lookups to fail. If this is a problem, the value can be adjusted by increasing the cut-off value:

 echo 8096 > /sys/module/apparmor/parameters/path_max

Profile doesn't conform to protocol

This is caused by a mismatch between what the policy is compiled into and what the kernel expects. Generally speaking this is caused by a bug in either the apparmor_parser (parser is generating bad policy) of the kernel module (kernel is not accepting valid policy).

Generally the quick fix is recompiling the apparmor_parser against the current kernel headers.

Policy Rules

Why does AppArmor not have separate permissions for file rename and file copy?

Because having a separate rename permission only gives a small amount of extra control over just mediating file copy. That is, having a separate file rename permission encodes expected behavior of how the data is expected to be moved, while file copy just worries about whether a file's contents can be copied. As long as reading the source and writing to the destination are allowed, rename restrictions can be worked around simply by copying the files' contents to the destination.

In the end, the trade-off in extra control over complexity for this feature was considered not worth implementing at this time.

Does specifying directory write access (e.g. /foo/ w) allow unlinking or renaming of files in the directory?

No, write permission on a directory does not imply permission to write to or create files in that directory. This type of access only gives write access to the directory itself, which means you are allowed to change the directory meta information (chown, chmod, etc.) and create/remove the directory.

AppArmor & Other LSMs

Can AppArmor be used simultaneously (stacked) with SELinux or other LSMs?

No, the LSM does not currently allow for generic stacking. While technically possible to stack two LSMs, both LSMs must cooperate. AppArmor, SELinux, Smack, and TOMOYO all make use of security structures that make cooperatively stacking difficult without modification.

Can an AppArmor profile be automatically converted to SELinux policy or vice versa?

No, there is currently no tool to do this nor is it generally possible. While AppArmor profiles and SELinux policies share a lot in common and can be used as a basis for each other, there are semantic differences that are not easily converted. Some examples of differences are:

  • AppArmor encodes certain expected behavior semantics in its profiles (e.g. 'm' versus the different forms of 'x')
  • AppArmor and SELinux handle domain transitions differently
  • AppArmor and SELinux handle user space directed domain transitions differently
  • Because they use some of the LSM hooks differently, there can be semantic policy differences
  • SELinux policy tends to consider the system as a whole while AppArmor policy is generally application by application.

While it is possible to create a tool that would automatically convert AppArmor profiles and SELinux policy, the converted policy would be incomplete which is why this tool has not been created.