Skip to content

Managing profiles

View profiles

AppArmor has several predefined profiles /etc/apparmor.d/. Some of the profiles are disabled and others are active.

To check all the available profiles:

ls /etc/apparmor.d/

Load profiles

apparmor_parser -C /etc/apparmor.d/profile.name

Alternatively, restart AppArmor which will reload all of the profiles:

systemctl reload apparmor.service

Disabe profiles

Add a symlink to the profile file in /etc/apparmor.d/disable/ directory.

Can I rename a profile filename to disable the profile?

No. The profile filename does not determine whether a profile gets loaded.

Remove profiles

apparmor_parser -R /etc/apparmor.d/profile.name

Does editing/removing a file in /etc/apparmor.d/ affect the enforced policy?

No. To change the enforced policy, changes must be loaded into the kernel. You must restart apparmor:

 /etc/init.d/apparmor restart

If you modify a profile with logprof or genprof, the tool with reload the profile for you.

Replace existing profiles

You can replace a loaded profile with a new version. When a profiles is replaced, all processes using the old profile start using the new profile for all access decisions going forward.

Replacing profiles has several security implications:

  • Processes retain access to all resources they had open under the older version of the profile
  • Any children processes retain the confinement that was decided by the old version of the profile. For children inheriting a parent profile (ix), new children processes will use the new profile.

The most secure solution is to always restart services after a profile has been updated, but in practice this is not always desired or required, which is why replacement is provided despite the above limitations.

To replace a profile: 

apparmor_parser -r /etc/apparmor.d/profile.name

Replacement vs removing and loading

Yes, removing a profile removes the confinement information from currently running processes making them unconfined. Once the new profile is loaded, it cannot be attached to already running unconfined processes.

Modifying profiles on the fly

Profiles cannot be loaded to already unconfined running processes. For processes that are already confined, you can perform profile replacement.

Why can't profiles be modified?

There are technical limitations after the changes introduced to the kernel as well as serious security considerations:

  • The process may have already accessed resources that the new profile would not allow
  • The process may have already launched applications that wouldn't be allowed under the new profile
  • The process may have launched children that have different confinement than what the new profile would have allowed. For example, in the simplest case the process and its children are all unconfined such that all the processes could be walked and correct confinement assigned, with the caveat that the process may have access to resources it shouldn't. In the worst case, the different operating environment caused by the confinement changed the behavior of the process so that it or its children are in a different state that is not functionally compatible with the new profile being applied to it.

But couldn't earlier versions of AppArmor do this?

Yes. AppArmor 2.0.1, 2.1, and 2.3 provide the ability to change the profile on a specific process through a set_profile interface. This interface was removed.

If setting a tasks confinement after the fact is so problematic, why was it offered in the first place?

This was initially implemented both because it is convenient and because imperfect confinement may be better than no confinement. Sometimes it is not possible or desired to shutdown a service and restart it when you would like to mitigate a possible breach of security.