AppArmor boolean RFC

[doublez13]

NOTE: This PR relies on an upstream AppArmor patch that has been merged, but not included in a tagged release yet.

As I was writing a policy for yara (a malware scanner), I thought it might be useful to implement something analogous to SELinux booleans. The idea is that chunks of policy can be enabled or disabled by booleans that are controlled in a single file.

For instance, the following SELinux booleans control the policy for AV programs:

# getsebool -a | grep antivirus
antivirus_can_scan_system --> off
antivirus_use_jit --> off

# semanage boolean -l | grep antivirus
antivirus_can_scan_system      (off  ,  off)  Allow antivirus to can scan system
antivirus_use_jit              (off  ,  off)  Allow antivirus to use jit

In this yara policy, I've implemented a boolean that controls whether or not yara has permission to read and trace other processes. In my opinion, this should be disabled by default, which would only allow yara to read files. Enabling this boolean allows yara (and any other AV policy that implements it) to scan another process's memory.

This PR is just an RFC and couldn't be merged until the AppArmor patch gets in a tagged release and pushed to distros.
I'm more interested to hear opinions on whether booleans are something you think would be beneficial to the AppArmor policies.

[roddhjav]

This will have to wait for the feature to be supported in a released AppArmor version, but I am 100% in with this. It is actually already planned in the roadmap: https://apparmor.pujol.io/development/roadmap/#next-features:

• Conditions
  • Integrate the new condition feature in the profiles and restrict them a lot according to the application actually in use. Eg: Gnome | KDE, X11 | Wayland, etc.
  • Create a new aa-config tool, similar to seboolean, to manage various settings, based on conditions.

[doublez13]

The required patch has landed in AppArmor 4.1.

[roddhjav]

Sadly, full condition support has not landed in apparmor 4.1. Therefore, it will have to wait for the next version (or even possibly apparmor 5.0)