Limitations of AppArmor based Enforcement

Currently KubeArmor does not (full) 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.

KubeArmor leverages AppArmor sub-profiles to implement from source based rules to restrict/gain access by a process/binary. For example, the following KubeArmor Security Policy can be used to restrict access of binary /bin/ls from source /bin/dash.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-group-1-block-proc-path-from-source
  namespace: multiubuntu
spec:
  severity: 5
  message: "block /bin/bash executing /bin/ls"
  selector:
    matchLabels:
      group: group-1
  process:
    matchPaths:
    - path: /bin/ls
      fromSource:
      - path: /bin/dash
  action:
    Block

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.

Therefore, KubeArmor does not support policies with from source rules for the Kubernetes deployments with security context as allowPrivilegeEscalation:false, on another KubeArmor still do support non from source rule-based policies in such constrained security context. For example, The following KubeArmor Security policy can be applied to block access to the binary /bin/sleep.

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-group-1-block-proc-path
  namespace: multiubuntu
spec:
  severity: 5
  message: "block /bin/sleep"
  selector:
    matchLabels:
      group: group-1
  process:
    matchPaths:
    - path: /bin/sleep
  action:
    Block