Skip to content

About AppArmor

What is AppArmor?

AppArmor is Mandatory Access Control (MAC) security system for Linux. AppArmor confines individual programs to a set of files, capabilities, network access and rlimits, collectively known as the AppArmor policy for the program, or simply as a profile. New or modified policy can be applied to the running system without a reboot. AppArmor aims to be easy to understand and use for most common requirements by presenting its profiles in an administrator friendly language.

AppArmor is selective in its confinement such that some programs on the system may be confined, while others not. Selective confinement allows an administrator the flexibility to turn off a problematic profile for troubleshooting while leaving other parts of the system confined.

Unconfined programs are run under standard Linux Discretionary Access Control (DAC) security. AppArmor augments traditional DAC in that confined programs are evaluated under traditional DAC first and if DAC allows the behavior then AppArmor policy consulted.

What is Default Deny (Allow listing)

Default deny describes the default action applied to a request that is not listed in policy, in this case deny. Policy that is based on default deny provides a list of actions that are allowed and any thing not listed in policy is denied.

Default deny is considered more secure than default allow because it only allows known good behavior.

What is Default Allow (Block listing)

Default allow describes the default action applied to a request that is not listed in policy, in this case allow. Policy that is based on default allow provides a list of actions that are NOT allowed and any thing not listed in the policy is allowed.

Default allow is considered less secure than default deny because it only stops known bad behavior.

Is AppArmor policy Default Deny (Allow listing)

Yes, and no. AppArmor profiles are based on default deny, that is the rules list what is allowed and everything else is denied. AppArmor policy allows specifying rules to deny actions but these are convenience function to document known bad behaviors, or to specify actions that should never be allowed even if an rule allowing it was added to the profile.

At a system level AppArmor can be consider either default deny or default allow depending on how it is deployed. If AppArmor is deployed with a complete system policy so that all tasks are confined then the deployment can be considered default deny. However AppArmor allows policy to be deployed incrementally so that only a subset of the system is actually confined, in this case AppArmor could be considered to be default allow at the system policy level but anything that is confined is confined by policy that is default deny.

Isn't incremental deployment (ie only mediating a subset of the system) insecure?

No, or more simply, not any more so than running a Linux system without any MAC security. AppArmor, like all other MAC security systems in Linux, is applied after standard Unix DAC permissions are applied. While true that confining only certain applications on a system is not as secure as having a policy for all applications, this is a trade off in policy versus ease of deployment that an admin should be aware of.

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 (eg 'm' versus the different forms of 'x')
  • AppArmor and SELinux handle domain transitions differently
  • AppArmor and SELinux handle user space directed domain transitions (in AppArmor change_hat(), change_profile(), change_onexec()) differently
  • While AppArmor and SELinux both use the LSM, they use some of the hooks differently which can result in semantic policy differences
  • SELinux policy tends to consider the system as a whole while AppArmor policy is generally application by application, so any conversion would need to deal with differences caused by this view of the system.

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.