2
0
mirror of https://gitlab.com/apparmor/apparmor synced 2025-08-31 06:16:03 +00:00

Update Complain Mode

John Johansen
2023-11-15 16:39:42 +00:00
parent 87a585cbd1
commit 6300c7941f

@@ -2,9 +2,14 @@
learning application behavior
ALLOWED
# null-XXXX profiles
Complain mode can create special profiles that are used to track and learn application behavior of child processes. 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.
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.
The creation of the null-XXXX profile allows the child applications logging stream to treat
Eg.
```
@@ -27,7 +32,7 @@ In the example, because /usr/bin/cat is covered the ```ix``` rule it inherits th
## 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 ???
* 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