Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process policy with matchPaths/execname not effective with fromSource #1899

Open
vholer opened this issue Nov 21, 2024 · 0 comments
Open

Process policy with matchPaths/execname not effective with fromSource #1899

vholer opened this issue Nov 21, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@vholer
Copy link

vholer commented Nov 21, 2024

Bug Report

When trying to limit process execution in matchPaths in BPF-LSM, the execname does NOT work if also parent process is specified via fromSource. Without parent process (just execname), it works. If a command is specified instead as an absolute path, both combinations (without and with fromSource) work as expected.

So the only misbehaviour is execname + fromSource.

General Information

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

  • Kernel version (run uname -a)
    6.1.115-126.197.amzn2023.x86_64

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

Client Version: v1.31.2
Kustomize Version: v5.4.2
Server Version: v1.30.6-eks-7f9249a
  • KubeArmor version:
    kubearmor/kubearmor-operator:v1.4.3

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

---
apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: combined
spec:
  action: Allow
  process:
    matchPaths:
      - execname: zsh
      - execname: bash
      - execname: coreutils
      ### Works:
      # - path: /usr/bin/curl
      #   fromSource:
      #     - path: /bin/bash
      ### Does NOT work:                  <--------------
      - execname: curl
        fromSource:
          - path: /bin/bash
      ### Works:
      # - path: /usr/bin/curl
      ### Works:
      # - execname: curl
    matchDirectories:
      - dir: /usr/bin/
        recursive: true
        action: Block
  selector:
    matchLabels:
      app.kubernetes.io/component: www
  • Target containers/pods

To Reproduce

  1. Create pod with label app.kubernetes.io/component=www
  2. Get inside container, run bash
  3. Apply policy where execname+fromSource is used
    matchPaths:
      - execname: curl
        fromSource:
          - path: /bin/bash

Execution of curl fails!

== Alert / 2024-11-21 14:37:36.194540 ==
ClusterName: default
HostName: ip-10-200-163-49.us-east-2.compute.internal
NamespaceName: vh-test4
PodName: deployment-57f57fd47-k4xtv
Labels: app.kubernetes.io/name=appenv.fortrabbit.com,app.kubernetes.io/component=www,app.kubernetes.io/instance=vh-test4,app.kubernetes.io/managed-by=appenv-operator
ContainerName: vh-test4
ContainerID: 51bd1062d352eab09bd6bbbe3101df3499aca13cf79cf4161e347da894595ef2
ContainerImage: ghcr.io/fortrabbit/k8s-php-83:in-912@sha256:36d87c9c495e8bffa59c7ad8a42cca96f2eb20dc2b3d68e2cb5548900fa12800
Type: MatchedPolicy
PolicyName: combined
Severity: 1
Source: /bin/bash
Resource: /usr/bin/curl
Operation: Process
Action: Block
Data: lsm=SECURITY_BPRM_CHECK
Enforcer: BPFLSM
Result: Permission denied
Cwd: /
HostPID: 59357
HostPPID: 49878
Owner: map[Name:deployment Namespace:vh-test4 Ref:Deployment]
PID: 9958
PPID: 9834
ParentProcessName: /bin/bash
ProcessName: /usr/bin/curl
UID: 1.645352099e+09
  1. Reapply policy where path+fromSource is used instead:
    matchPaths:
      - path: /usr/bin/curl
        fromSource:
          - path: /bin/bash

Execution of curl now proceeds.

Obviously there is some inconsitency when evaluating curl execution with fromSource between execname and path.

Expected behavior

When curl is allowed to run via execname with fromSource, it should allow running a process, but does not.

    matchPaths:
      - execname: curl
        fromSource:
          - path: /bin/bash
@vholer vholer added the bug Something isn't working label Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant