AppArmor not working with lenient policies

[rksharma95]

General Information

• Environment description: k3s
• Kernel version (run uname -a): 5.15.0-56-generic
• Orchestration system version in use (e.g. kubectl version, ...)
• Link to relevant artifacts (policies, deployments scripts, ...)
• Target containers/pods: vault-
• Enforce: Apparmor

To Reproduce

1. deploy hashicorp vault
2. apply the following lenient policy:

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-vault-protect
  namespace: default
spec:
  action: Allow
  file:
    matchDirectories:
    - action: Block
      dir: /vault/
      recursive: true
    - dir: /
      recursive: true
    - dir: /vault/
      fromSource:
      - path: /bin/vault
      recursive: true
  process:
    matchPaths:
    - path: /bin/sh
    - path: /bin/vault
    - path: /bin/busybox
  selector:
    matchLabels:
      app.kubernetes.io/name: vault
      component: server
  severity: 7

3. access /vault/ inside vault-0 pod, i.e.

kubectl exec -it vault-0 -- sh -c "cat /vault/config/extraconfig-from-values.hcl"

Expected behavior

as per the applied policy any access to the /vault/ directory should be blocked except access by the /bin/vault binary.

[rksharma95]

It seems like a blocker at Apparmor's side it's related to how Apparmor works when it comes to transition to a sub-profile for a process to gain more privileges/permissions. for a process to gain more (file) capability than it's parent process the process must have no_new_privs flag unset on it.

when a pod container is configured with allowPrivilegeEscalation: false security context (as in case of vault) then it makes flag no_new_privs set on the container processes [ref] and it will not be possible for a process to change it's apparmor (sub)profile.

i asked it on apparmor gitlab repo by creating an issue and according to a reply on this issue currently it's not possible to achieve implementation of such apparmor profile if the no_new_privs flag is set for the container process.

[rksharma95]

this issue is not limited to the lenient policies, in a runtime env with allowPrivilegeEscalation: false for any apparmor policy if a process/binary need to change it's apparmor profile by transitioned to a sub-profile with additional capabilities/permissions added then it will be an issue.

for example:

1. deploy an ubuntu deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ubuntu-deployment
  namespace: default
  labels:
    deployment: ubuntu
spec:
  replicas: 1
  selector:
    matchLabels:
      group: group-1
      container: ubuntu
  template:
    metadata:
      labels:
        group: group-1
        container: ubuntu
    spec:
      containers:
        - name: ubuntu-container
          image: kubearmor/ubuntu-w-utils:0.1
          securityContext:
              allowPrivilegeEscalation: false

2. apply this policy

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: ksp-ubuntu-allow-file-path-owner-readonly-from-source-path
  namespace: default
spec:
  severity: 10
  message: "a critical file was accessed"
  tags:
  - WARNING
  selector:
    matchLabels:
      container: ubuntu
      group: group-1
  process: # base whitelisting rules
    matchPaths:
    - path: /home/user1/readwrite
      fromSource:
      - path: /bin/su    
    matchDirectories:
    - dir: /bin/ # required to change root to user1 / try 'su - user1'
      recursive: true
    - dir: /usr/bin/ # used in changing accounts
      recursive: true  
  file:
    matchPaths:
    - path: /home/user1/secret_data1.txt
      readOnly: true
      ownerOnly: true
      fromSource:
      - path: /readwrite
      - path: /bin/su
    - path: /root/.bashrc # used by root
    - path: /root/.bash_history # used by root
    - path: /home/user1/.profile # used by user1
    - path: /home/user1/.bashrc # used by user1
    - path: /run/utmp # required to change root to user1
    - path: /dev/tty
    matchDirectories:
    - dir: /etc/ # required to change root to user1 (coarse-grained way)
      recursive: true
    - dir: /proc/ # required to change root to user1 (coarse-grained way)
      recursive: true
  action:
    Allow

3. exec into the pod and execute

$ ./readwrite -r /home/user1/secret_data1.txt
bash: ./readwrite: Operation not permitted

[rksharma95]

To conclude on this issue, at this point it is not possible/feasible to (full) support enforcement leveraging Apparmor enforcer, in cases where Kubernetes deployments with a security Context defined with allowPrivilegedEscalation set to false.
For reference, the discussion took place here on this issue on Apparmor project repo regarding Apparmor and no_new_privs flag interaction when it comes to Apparmor sub-profiles transition,

[daemon1024]

Can you add a document explaining this as part of wiki? Then we can close the issue. Thanks a lot @rksharma95

[rksharma95]

PTAL @daemon1024 @nyrahul
https://github.com/kubearmor/KubeArmor/wiki/Limitations-of-AppArmor-based-Enforcement

[daemon1024]

@rksharma95 some points:

1. We do support generic non from source based policies, like a simple process allow/block list even with the specific security context
2. Need to add that KubeArmor leverges profile transitions to enforce from source based policies

[rksharma95]

@rksharma95 some points:

1. We do support generic non from source based policies, like a simple process allow/block list even with the specific security context

2. Need to add that KubeArmor leverges profile  transitions to enforce from source based policies

updated the wiki, PTAL @daemon1024 thanks

[daemon1024]

LGTM, Thanks a lot for seeing this through 🙌🏽