mir/apparmor
2
0
Fork 0
mirror of https://gitlab.com/apparmor/apparmor synced 2025-08-31 06:16:03 +00:00
Code Issues Releases Wiki Activity

Update Complain Mode

John Johansen
2023-11-15 18:40:11 +00:00
parent eda578f602
commit 64e7ccb661
1 changed files with 37 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
Complain-Mode.md

@@ -1,13 +1,31 @@
# Complain mode
learning application behavior
learning application behavior TODO
ALLOWED
# null-XXXX profiles
When an application executes another application profile rules are used to determine the confinement of the subsequent application. However applications in complain mode often do not have a fully developed profile and the confinement of the child application may not be defined. 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-" 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.
# 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
@@ -15,29 +33,27 @@ into new child profile
The creation of the null-XXXX profile allows the child applications logging stream to treat
Eg.
```
$ cat ex
profile ex flags=(complain) {
# ??? todo rest of minimal rule set for example
/usr/bin/** ix,
}
$ aa-exec -ip ex -- /usr/bin/cat /proc/self/attr/current
ex
$ which aa-status
/sbin/aa-status
$ aa-exec -ip ex -- aa-status | grep null-
#???? TODO
```
In the example, because /usr/bin/cat is covered the ```ix``` rule it inherits the "ex" profile, from aa-exec. However the ex profile does not have a rule that matches /sbin/aa-status, so a special null-/sbin/aa-status profile is created to track its execution.
null profiles are in complain mode
## Variants of the null-XXXX profile
### 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. <br><br>eg. null-1234<br>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.<br><br>eg. null-/usr/bin/bash<br>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.