AppArmor Profile Flags

The profile flags allow modifying the behavior of the profile. If a profile flag is specified it takes priority over any conflicting flags that have been specified by rules in the profile body.

Profile Modes

The profile mode allow controlling the enforcement behavior of the profile rules. Profile modes are mutually exclusive.

If no mode is specified the profile defaults to enforce mode.

enforce - For a given action, if the profile rules do not grant permission the action will be denied, with an EACCES or EPERM error code returned to userspace, and the violation will be logged with a tag of the access being DENIED.
kill (new AppArmor 4.0) - This is a variant of enforce mode where in addition to returning EACCES or EPERM for a violation, the task is also sent a signal to kill it.
complain - For a given action, if the profile rules do not grant permission the action will be allowed, but the violation will be logged with a tag of the access being ALLOWED.
prompt (new AppArmor 4.0) - This is a variant of complain mode where the access request is sent to a user space daemon to determine if it is allowed. This only works with select rules and only if supported by the kernel. If the usespace daemon is not present the access request will be denied.
unconfined (new AppArmor 4.0) - This mode allows a task confined by the profile to behave as though they are I. This mode allow for an unconfined behavior that can be later changed to confinement by using profile replacement. This mode is should not be used under regular deployment but can be useful during debugging and some system initialization scenarios.
default_allow (new AppArmor 4.0) - This mode facilitates writing profiles in that allow everything by default. This is not normally recommended but facilitates creating basic profiles while working to transition policy away from unconfined. This mode is being added specifically to replace the use of the unconfined flag in these transitional profiles as the use of unconfined in policy is confusing and does not reflect the semantics of what is being done. Generally the goal for policy should be to remove all default_allow profiles once the policy is fully developed.

kill control

kill.signal=XXX (new AppArmor 4.0) - set the signal that apparmor will send when kill is being used on a task.

Audit Control flags

The audit mode allows control of how AppArmor messages are are logged to the audit system.

audit - This flag causes all actions whether allowed or denied to be logged.
audit.mode=XXX (new AppArmor 4.0) - modify the audit flags behavior
- normal - default behavior
- quiet
- quiet_denied
- no_quiet
- all

namespace controls

attach_disconnected - This forces AppArmor to attach disconnected objects to the task's namespace and mediate them as though they are part of the namespace. WARNING this mode is unsafe and can result in aliasing and access to objects that should not be allowed. Its intent is a debug and policy development tool.
attach_disconnected.path=XXX (new AppArmor 4.0) - If attach_disconnected is in use attach disconnected object to the supplied path instead of the root of the namespace.
chroot_relative - This forces file names to be relative to a chroot and behave as if the chroot is a mount namespace.

Misc modes

mediate_deleted - This forces AppArmor to mediate deleted files as if they still exist in the file system.
debug (new AppArmor 4.0) - This allow per profile control of when debug messages should be sent to the kernel ring buffer. The type of messages will depend on how the kernel was built. It should never be enabled during normal operation.
interruptible (new AppArmor 4.0) - This allows hinting to the kernel that upcalls can be interruptible. The kernel does not have to respect this flag. It is considered a debug option for use by developers.