From AppArmor
Jump to: navigation, search


  • AppArmor 2.3: namespaces
  • AppArmor 3.5: stacking AppArmor
  • AppArmor 4: delegation, variants, subtypes, instances, aliases

Profile names

Profile names can take on two forms, a name that defines an attachment (file name) or a more restricted non-attaching profile name.

Profile names that define an attachment can have the following form


Profiles names that are non-attaching have the following form


Profile names must begin with an alphanumeric character or the / character

Profile names do not end with / character

// - profile and namespace hierarchy seperator


Special Prefixes

null- reserved for the special dynamically created learning profiles


: - namespace

 :ns1:profile       # ssh style
 :ns1://profile     # url style

& - Stacking


+ - Delegation


~ - profile variant (user name or other conditional match)


# - instance == dynamic variant created by change_instance, where the trailing # is unique. This will only ever show up as the last element of a label.

instance of profile_A


instance of profile_A//&profile_B


* - subtype of a profile, where the number is unique to the permission division. Subtypes only show up in specific queries that request them. They are not meant for regular user space consumption but are made available to user space that libapparmor can provide a permission lookup cache.


The subtype is a per profile value so that *1 in conjunction with profile A is different than *1 with profile B. The subtype will always show up as part of the profile it is associated with.

The subtype of a child is expressed as


Subtypes in a stack



AppArmor 4 allows for Aliases to be used for profiles, stacks and delegation, allowing for shortened names to be used. Aliases are declared at the profile level, or when in a profile for its children, using the alias command

 'alias' <name>'='<name>','
   alias shorty=A//&B//+C,

It is important to note that an alias is only guaranteed to be used in the case of an exact label match. That is given the label A//&B//+C the name shorty will be used. However given another label even if the label contains the aliased label the alias may or may not be used. Whether it will be used is an implementation issue, with the general rule being if an alias is a perfect subset of a label name string, with no overlap with other aliases it might be used.

 Eg. 1
   alias shorty=A//&B//+C,
   label A//&B//+C//&D,
reported label shorty//&D
 Eg. 2
   alias shorty=A//&C//+D,
   label A//&B//&C//+D,
reported label A//&B//&C//+D
the B in the text string keeps the alias from being an exact match so the alias will likely not be used.

Note: an implementation is free to use the alias in Eg 2. Which would result in the reported label shorty//&B. The reason it is not guaranteed is because there is a runtime cost to compute whether an alias should be used, and with potentially overlapping aliases finding consistent minimal label names is difficult and costly.

Aliases with in policy

Even though an alias may not be reported by the AppArmor kernel module for a given label, policy is free to specify it as long as it is declared in the policy that is being loaded together as a single unit. This ensures that the kernel knows of the alias and can parse it correctly. So using Eg. 2 even if the kernel does not report shorty//&B the policy author is free to use it.

Aliases may even be used in declaring other aliases as long as the expand results in a label name that contains only profiles.

 Eg. 3
  alias shorty=A//&B//+C,
  alias foo=shorty&//D,

Aliases declared as such will be reported from the kernel based on matching of the expanded form.

Aliasing profile names

Aliases for profile names are not supported at this time. If desired or needed it is recommend shortend profile names be used along with the separated attachment specification.

 Eg.  Instead of
   profile /usr/lib/firefox/firefox{,*[^s][^h]} { ... }
use profile firefox /usr/lib/firefox/firefox{,*[^s][^h]} { ... }