kubearmor / KubeArmor

Runtime Security Enforcement System. Workload hardening/sandboxing and implementing least-permissive policies made easy leveraging LSMs (BPF-LSM, AppArmor).
https://kubearmor.io/
Apache License 2.0
1.5k stars 345 forks source link

policy matching with relative path access has issues with telemetry/alerts #750

Closed nyrahul closed 2 months ago

nyrahul commented 2 years ago

Bug Report

KubeArmor requires that you specify an absolute path in the policy rules. However, when the actual access happens with the relative path, the action is honored, but the policy name/severity/message is not populated with appropriate policy details (defaultPosture is specified as the policy name).

General Information

Environment description (GKE, VM-Kubeadm, vagrant-dev-env, minikube, microk8s, ...)

I tried with k3s

Kernel version (run uname -a)

Linux ubuntu2004-vagrants 5.4.0-120-generic #136-Ubuntu SMP Fri Jun 10 13:40:48 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Orchestration system version in use (e.g. kubectl version, ...)

Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.1", GitCommit:"86ec240af8cbd1b60bcc4c03c20da9b98005b92e", GitTreeState:"clean", BuildDate:"2021-12-16T11:41:01Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.6+k3s1", GitCommit:"3228d9cb9a4727d48f60de4f1ab472f7c50df904", GitTreeState:"clean", BuildDate:"2022-01-25T01:27:44Z", GoVersion:"go1.16.10", Compiler:"gc", Platform:"linux/amd64"}

Link to relevant artifacts (policies, deployments scripts, ...)

apiVersion: security.kubearmor.com/v1
ind: KubeArmorPolicy
etadata:
 name: ksp-wordpress-block-config
 namespace: wordpress-mysql
pec:
 severity: 10
 message: "blocked access to wordpress configuration file"
 selector:
   matchLabels:
     app: wordpress
 file:
   matchPaths:
   - path: /var/www/html/wp-config.php
     fromSource:
     - path: /bin/cat
 action:
   Block

Target containers/pods

kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/main/examples/wordpress-mysql/wordpress-mysql-deployment.yaml

To Reproduce

  1. Install wordpress-mysql deployment kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/main/examples/wordpress-mysql/wordpress-mysql-deployment.yaml
  2. Apply policy specified above
  3. Execute kubectl exec -it -n wordpress-mysql wordpress-XXXXXXXX -- bash -c "cat wp-config.php"
  4. Execute kubectl exec -it -n wordpress-mysql wordpress-XXXXXXXX -- bash -c "cat /var/www/html/wp-config.php"

Actual vs Expected behavior

Actual Behavior

  1. Access to wp-config.php should be denied. (This is working)
  2. The alert that is generated should have PolicyName: ksp-wordpress-block-config.
    • With Step 3 above, this PolicyName is DefaultPosture
    • With Step 4 above, the policy name is appropriately set.

Expected Behavior

The PolicyName should be correctly set to ksp-wordpress-block-config in both the cases where absolute or relative path accesses are made.

{
  "Timestamp": 1656682358,
  "UpdatedTime": "2022-07-01T13:32:38.159601Z",
  "ClusterName": "default",
  "HostName": "ubuntu2004-vagrants",
  "NamespaceName": "wordpress-mysql",
  "PodName": "wordpress-bf95888cb-jvcxh",
  "Labels": "app=wordpress",
  "ContainerID": "527562795ec2c4b68573e25f5cddb33c8114117a012c588a7121407e684fcf30",
  "ContainerName": "wordpress",
  "ContainerImage": "docker.io/library/wordpress:4.8-apache@sha256:6216f64ab88fc51d311e38c7f69ca3f9aaba621492b4f1fa93ddf63093768845",
  "HostPPID": 1897055,
  "HostPID": 1897061,
  "PPID": 1897055,
  "PID": 1330,
  "ProcessName": "/bin/cat",
- "PolicyName": "DefaultPosture",     # <----- Actual
+ "PolicyName": "ksp-wordpress-block-config",    # <---- Expected
  "Type": "MatchedPolicy",
  "Source": "/bin/cat wp-config.php",
  "Operation": "File",
  "Resource": "wp-config.php",
  "Data": "syscall=SYS_OPEN flags=O_RDONLY",
  "Enforcer": "AppArmor",
  "Action": "Block",
  "Result": "Permission denied"
}
DelusionalOptimist commented 2 years ago

@nyrahul has this been fixed? I'm getting the correct PolicyName with the latest changes. 2022-07-13_19-37

nyrahul commented 2 years ago

Closing this issue since this does not seem to be a problem anymore based on test results.