Block policy is not enforcing as expected

[salman-accuknox]

Bug Report

General Information

• Environment: GKE
• Kernel version (run uname -a):

Linux cs-891809400264-default-boost-p5lbm 5.10.68+ #1 SMP Wed Dec 1 10:07:21 UTC 2021 x86_64 GNU/Linux

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

Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.5-gke.1302", GitCommit:"639f3a74abf258418493e9b75f2f98a08da29733", GitTreeState:"clean", BuildDate:"2021-10-21T21:35:48Z", GoVersion:"go1.16.7b7", Compiler:"gc", Platform:"linux/amd64"}

• Target : pods

To Reproduce

1. Deploy Sample Application

kubectl apply -f https://raw.githubusercontent.com/accuknox/microservices-demo/main/release/kubernetes-manifests.yaml

2. Apply Policy to block access to /etc/passwd of frontend pod from server

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: block-passwd-frontend
  namespace: default # Change your namespace
spec:
  message: "Accessed passwd file using web"
  selector:
    matchLabels:
      app: frontend # use your own labels
  file:
    severity: 5
    matchPaths:
    - path: /etc/passwd
      fromSource:
      - path: /src/server # change with your frontend entrypoint 
    action: Block

3. Goto External_IP/lfi?file=/../../../etc/passwd

$ kubectl get svc | grep frontend
frontend                ClusterIP      10.116.4.217    <none>          80/TCP                        48s
frontend-external       LoadBalancer   10.116.15.170   35.236.53.241   80:32383/TCP,8080:31393/TCP   47s

URL

http://35.236.53.241/lfi?file=/../../../etc/passwd

Expected behavior

Permission Denied Shown in UI

Action: Block and Result: Permission Denied in kubearmor logs

Current behavior

/etc/passwd file shown in UI

Action: Block and Result: Passed in kubearmor logs

Logs karmor log

== Alert / 2021-12-27 06:42:29.799162 ==
Cluster Name: Default
Host Name: gke-cluster-1-default-pool-840bc104-8fr7
Namespace Name: default
Pod Name: frontend-7556575bcc-5rwqg
Container ID: 7feac4cd3fb82558a547232a9d8d6940e3608cfe7d624cab5377b93af7a90820
Container Name: server
Policy Name: block-passwd-frontend
Severity: 5
Message: Accessed passwd file using web
Type: MatchedPolicy
Source: server
Operation: File
Resource: /etc/passwd
Data: syscall=SYS_OPENAT fd=-100 flags=/../../../etc/passwd
Action: Block
Result: Passed

karmor sysdump

[nyrahul]

I think the problem here is relative file access of /etc/passwd ... In the policy there is absolute file path specified but when the access is attempted, a relative path is used. This is a problem. CC @nam-jaehyun

@salman-accuknox , lets confirm this hypothesis? Can you please access the /etc/passwd using an absolute path (for e.g, you can bash into the container and use cat /etc/passed) and check if the policy is enforced? Thanks

[salman-accuknox]

So it is auditing file access from UI(server) correctly. Like I m getting logs only when the file access occurred from the web(server).

Yes. If I enforce a rule like this.

file:
    severity: 5
    matchPaths:
    - path: /etc/passwd
#      fromSource:
#      - path: /src/server # change with your frontend entrypoint 
    action: Block

Then I m getting the result. Here it also blocks relative file access.

root@frontend-7556575bcc-xrwkf:/src# cat /etc/passwd
cat: /etc/passwd: Permission denied
root@frontend-7556575bcc-xrwkf:/src#

[nam-jaehyun]

@salman-accuknox it means that /src/server may not be the subject that accesses /etc/passwd. /src/server may just receive some outputs from other processes (e.g., shells).

[salman-accuknox]

@nam-jaehyun Okay. But /src/server is initiating that right? Also, I m getting server in the source field also.

[nyrahul]

This seems to be an invalid issue. Closing it since it has been dormant for long.