Limitations of AppArmor based Enforcement

Currently KubeArmor does not support enforcement leveraging Apparmor in cases where Kubernetes Deployments are configured with a security context allowPrivilegeEscalation is set to false.

Introduction

Apparmor is a Linux Security Module (LSM) included in the Linux kernel since version 2.6.36. It can be used to implement mandatory access control (MAC) by developing a security profile. A security profile can confine an application by defining a list of files, operations and capabilities an application is allowed or restricted to access. Apparmor sub-profiles provide fine-grained control over confinement at the sub-process/sub-program level by transitioning to sub-profile at execution time.

Privilege Escalation and AppArmor Sub-profiles

When a sub-process requires more privileges/permission than its parent process it requires the no_new_privs to be unset on it. For example, when an application is confined such that its subprocess requires some additional capabilities/permission than itself, in that case, the subprocess requires no_new_privs to be unset for it.

Apparmor requires interaction with no_new_privs to transition to a sub-profile. This issue has been discussed in detail here on this issue on AppArmor Gitlab repository, there's an ongoing discussion to eliminate the no_new_privs to stacking a sub-profile which is part of the analysis to be implemented as a stable feature to the KubeArmor.

Security Context allowPrivilegeEscalation and no_new_privs

When a Kubernetes pod container is configured with allowPrivilegeEscalation: false as a security context then it makes flag no_new_privs set on the container processes [ref] and it will not be possible for a process to transition to an AppArmor sub-profile. This issue on KubeArmor discusses this problem in the context of Hasicorp Valut deployment.