Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-3128

grant access to unprivileged containers to the kubelet podresources socket

    • None
    • Critical
    • rhel-sst-container-tools
    • 3
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • If docs needed, set a value
    • Unspecified
    • None

      Description of problem:
      containerized workloads running as container_t wants to connect to the kubelet podresources API through a unix domain socket sitting at `/var/lib/kubelet/pod-resources/kubelet.sock`

      Both `/var/lib/kubelet/pod-resources/kubelet.sock` and `/var/lib/kubelet/pod-resources/kubelet.sock` are currently labeled as `container_var_lib_t`.

      They should probably treated as device plugins

      This is specially important to enable the numa-aware scheduler (

      Version-Release number of selected component (if applicable):
      selinux-policy-38.1.8-1.el9.noarch
      selinux-policy-targeted-38.1.8-1.el9.noarch
      container-selinux-2.199.0-1.el9.noarch

      How reproducible:
      100%

      Steps to Reproduce:
      1. run unprivileged container, mount the kubelet podresources socket (see attached example yaml)
      2. try to access to the podresources socket. Example test client available at https://github.com/k8stopologyawareschedwg/podresourcesapi-tools/releases/tag/v0.0.1 - `podrescli --podresources-socket unix:///host-podresources-socket/kubelet.sock`
      3.

      Actual results:
      avc denials:
      ```
      type=AVC msg=audit(1679405027.674:79402): avc: denied

      { write } for pid=2236325 comm="podrescli" name="kubelet.sock" dev="sdb4" ino=144703618 scontext=system_u:system_r:container_t:s0:c25,c26 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=sock_file permissive=0
      type=AVC msg=audit(1679405031.376:79403): avc: denied { write }

      for pid=2236496 comm="podrescli" name="kubelet.sock" dev="sdb4" ino=144703618 scontext=system_u:system_r:container_t:s0:c25,c26 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=sock_file permissive=0
      type=AVC msg=audit(1679405032.046:79404): avc: denied

      { write }

      for pid=2236590 comm="podrescli" name="kubelet.sock" dev="sdb4" ino=144703618 scontext=system_u:system_r:container_t:s0:c25,c26 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=sock_file permissive=0
      ```

      Expected results:
      access should be granted

      Additional info:
      at the moment we are using a custom policy. We can keep using this a stopgap fix. The policy is also broken with the above package

      policy: https://github.com/k8stopologyawareschedwg/deployer/blob/main/pkg/assets/rte/selinuxpolicy-ocp411.cil
      denials:
      ```
      type=AVC msg=audit(1679044968.338:5383): avc: denied

      { connectto }

      for pid=10664 comm="resource-topolo" path="/var/lib/kubelet/pod-resources/kubelet.sock" scontext=system_u:system_r:rte.process:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
      ```
      In that (different nightly though) system the label was
      ```
      srwxr-xr-x. 1 root root system_u:object_r:container_var_lib_t:s0 0 Mar 15 22:02 /var/lib/kubelet/pod-resources/kubelet.sock
      ```

              rhatdan Daniel Walsh (Inactive)
              fromani@redhat.com Francesco Romani
              Container QE Container QE Container QE Container QE
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: