Complain mode

learning application behavior TODO

ALLOWED

exec and complain mode

When an application executes another application profile x rules are used to determine the confinement of the subsequent application.

Eg.

  px /usr/bin/**,

Instructs apparmor to find a matching profile for applications under /usr/bin/. In complain mode x rules are still enforced and the profile transition (or not) dictated by the rule will be applied. If the profile is transitioned the child application will be governed by the specified profile, including that profiles mode. That is to say complain mode is not inherited at the task/application level but is a property of the profile doing the confinement, and is only guaranteed to be inherited if the profile in complain mode is inherited.

However applications in complain mode often do not have a fully developed profile and the confinement of the child application may not be defined (there is no rule in profile matching the executed application). Instead of folding the child applications behavior logging in to the current applications profile, apparmor can create special profiles that are used to track and learn application behavior of child processes. Specifically these special null-XXX profiles are created when a confined application in complain mode tries to exec another application and the profile has no matching rule that defines the expected behavior, or has a rule that explicitly says a special null-XXXX profile should be created.

The reason this is done is done is because at the time of the exec apparmor does not know what the intent of the exec is. To be able to continue learning the behavior of the application and its children apparmor needs to allow the execution and log its behavior. The question becomes how should apparmor proceed in logging the applications behavior.

*ix the application, logging under the calling applications profile. However this would result in the called applications behavior being treated as part of the current application extending the current applications profile which may not be the actual intent. *px the application to an existing profile (if it exists). While this will not result in extending the original applications profile beyond intent, running the application under a system defined profile might not be the intent either. The policy author may indeed want the original application's profile to encapsulate a utilities behavior, it might also want execute the profile under a child profile.

Instead to delay the decision about which profile the application should be executed under, apparmor creates a special null- profile for the application. This null- profile is responsible capturing the application's behavior, and then the behavior learned by the special null- profile can be used to create a new profile, or folded into an existing profile as part of profile development.

null-XXXX profiles

don't know in kernel if want to fold behavior of child into current into existing profile into new child profile

The creation of the null-XXXX profile allows the child applications logging stream to treat

null profiles are in complain mode

Variants of the null-XXXX profile

null-complain - this is the original version of the null-XXXX profile. The profile name was shared by all tasks attached to it. This made separating the logs of different applications difficult and in some cases impossible. This also made it so the application call hierarchy was generally not available in the logs and could only be recreated if all exec messages where present in the logs.
null-<unique number> - In this variant each new exec got a unique new null-XXXX profile with a unique to boot sessions number, making it much easier to distinguish log messages. This version however still made it difficult to tell which application the log should belong to, and could even make it impossible if the exec log message was dropped or not in the current log. It also resulted in unique profile numbers on each invocation of the same applications, making dedup harder. In addition this unique profile was now created as a child of the invoking profile so that call hierarchy was preserved and available during profile development.

eg. null-1234
ex//null-1234
null-<exe> - In this variant the application executable name is appended to the null- prefix. This made it so each log message carried the attached application information, and new invocations of the application shared the same null- profile. Like the null-<unique number> variant, these profiles were created as children of the invoking profile preserving the exec call hierarchy.

eg. null-/usr/bin/bash
ex//null-/sbin/aa-exec

known bugs

inheriting of mediation types being enforced

???

complain mode and deny rules

One some versions of apparmor broken .... TODO

Alternate possibility to null-XXX profiles - prompt for behavior

Using null-XXX profiles is not the only possible solution to dealing with the execution problem. If the application exec can be frozen and a prompt sent to the user to determine desired behavior before the application is run, then the null-profile would not be needed as the desired transition and needed profiles could be setup in advance.