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

podman play kube does not set selinux private labels #13840

Closed
fulminemizzega opened this issue Apr 12, 2022 · 6 comments
Closed

podman play kube does not set selinux private labels #13840

fulminemizzega opened this issue Apr 12, 2022 · 6 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@fulminemizzega
Copy link
Contributor

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description
Podman allows to use private SELinux labels for named volumes by adding :Z at the end of the bind mount specification. Looks like podman generate kube and podman play kube discard this setting and instead default to a SELinux shared label.

Steps to reproduce the issue: (as root on the host)

  1. Run this commands
podman pod create --name testpod
podman run -dt --pod testpod --name c1 -v pvol:/pvol:Z fedora-minimal sh
podman run -dt --pod testpod --name c2 -v shvol:/shvol:z fedora-minimal sh
podman exec -it c1 sh
ls -lZ
  1. The output is (see label before last ellipsis)
sh-5.1# ls -lZ
total 8
[...]
drwxr-xr-x.   2 root root system_u:object_r:container_file_t:s0:c262,c353    6 Jul 21  2021 opt
dr-xr-xr-x. 187 root root system_u:object_r:proc_t:s0                        0 Apr 12 13:47 proc
drwxr-xr-x.   2 root root system_u:object_r:container_file_t:s0:c262,c353    6 Apr 12 13:47 pvol
[...]
  1. Exit the container, then
podman exec -it c2 sh
sh-5.1# ls -lZ
[...]
drwxr-xr-x.   1 root root system_u:object_r:container_file_t:s0:c262,c353   42 Apr 12 13:47 run
lrwxrwxrwx.   1 root root system_u:object_r:container_file_t:s0:c262,c353    8 Jul 21  2021 sbin -> usr/sbin
drwxr-xr-x.   2 root root system_u:object_r:container_file_t:s0              6 Apr 12 13:47 shvol
[...]

So c1 has pvol with private label and c2 has shvol with a shared label. I also noticed that containers in a pod share the same SELinux label, I did not know that (c262,c353)
4. Exit the container, then
5. podman generate kube testpod -f play.yml
These are play.yml contents:

# Save the output of this file and use kubectl create -f to import
# it into Kubernetes.
#
# Created with podman-3.4.4
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2022-04-12T13:59:45Z"
  labels:
    app: testpod
  name: testpod
spec:
  containers:
  - command:
    - sh
    image: registry.fedoraproject.org/fedora-minimal:latest
    name: c1
    resources: {}
    securityContext:
      capabilities:
        drop:
        - CAP_MKNOD
        - CAP_NET_RAW
        - CAP_AUDIT_WRITE
    tty: true
    volumeMounts:
    - mountPath: /pvol
      name: pvol-pvc
  - command:
    - sh
    image: registry.fedoraproject.org/fedora-minimal:latest
    name: c2
    resources: {}
    securityContext:
      capabilities:
        drop:
        - CAP_MKNOD
        - CAP_NET_RAW
        - CAP_AUDIT_WRITE
    tty: true
    volumeMounts:
    - mountPath: /shvol
      name: shvol-pvc
  restartPolicy: Never
  volumes:
  - name: pvol-pvc
    persistentVolumeClaim:
      claimName: pvol
  - name: shvol-pvc
    persistentVolumeClaim:
      claimName: shvol
status: {}
  1. podman pod rm -f testpod
  2. podman volume rm pvol shvol
  3. podman play kube play.yml
  4. Check labels inside the new containers like before:
podman exec -it testpod-c1 sh
sh-5.1# ls -lZ
[...]
drwxr-xr-x.   2 root root system_u:object_r:container_file_t:s0:c194,c583    6 Jul 21  2021 opt
dr-xr-xr-x. 187 root root system_u:object_r:proc_t:s0                        0 Apr 12 14:03 proc
drwxr-xr-x.   2 root root system_u:object_r:container_file_t:s0              6 Apr 12 14:03 pvol
[...]
sh-5.1# exit
podman exec -it testpod-c2 sh
sh-5.1# ls -lZ
[...]
drwxr-xr-x.   1 root root system_u:object_r:container_file_t:s0:c194,c583   42 Apr 12 14:03 run
lrwxrwxrwx.   1 root root system_u:object_r:container_file_t:s0:c194,c583    8 Jul 21  2021 sbin -> usr/sbin
drwxr-xr-x.   2 root root system_u:object_r:container_file_t:s0              6 Apr 12 14:03 shvol
[...]

Describe the results you received: as you can see, both new containers (with new SELinux labels) have a named volume (pvol and shvol), both with shared label.

Describe the results you expected: pvol should have label system_u:object_r:container_file_t:s0:c194,c583 and shvol is fine.

Additional information you deem important: I think documentation of podman play kube should also be updated, right now in https://docs.podman.io/en/latest/markdown/podman-play-kube.1.html it says that "Note: hostPath volume types created by play kube will be given an SELinux private label (Z)".
Named volumes instead have a shared label, this (I think) should be added.

Output of podman version:

Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.16.8
Built:        Wed Dec  8 22:45:07 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.0-2.fc35.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.0, commit: '
  cpus: 2
  distribution:
    distribution: fedora
    variant: coreos
    version: "35"
  eventLogger: journald
  hostname: fcos
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.16.13-200.fc35.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 185884672
  memTotal: 1004912640
  ociRuntime:
    name: crun
    package: crun-1.4.3-1.fc35.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.4.3
      commit: 61c9600d1335127eba65632731e2d72bc3f0b9e8
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc35.x86_64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 746319872
  swapTotal: 753397760
  uptime: 86h 43m 59.96s (Approximately 3.58 days)
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 12
    paused: 0
    running: 6
    stopped: 6
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageStore:
    number: 32
  runRoot: /var/run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 1638999907
  BuiltTime: Wed Dec  8 22:45:07 2021
  GitCommit: ""
  GoVersion: go1.16.8
  OsArch: linux/amd64
  Version: 3.4.4

Package info (e.g. output of rpm -q podman or apt list podman):

podman-3.4.4-1.fc35.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

No

@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Apr 12, 2022
@rhatdan
Copy link
Member

rhatdan commented Apr 12, 2022

Kubernetes yaml files have no way to differentiate between :Z and :z, so we default to the most sharing.

@fulminemizzega
Copy link
Contributor Author

Then I think this should be added as another note to the docs, it all makes sense now... but only after reading a few comments here on github, like this #2575 (comment)

@rhatdan
Copy link
Member

rhatdan commented Apr 12, 2022

Please open a PR to how you want the docs to look.

@fulminemizzega
Copy link
Contributor Author

I'm not sure at this point if something has changed in podman 4, I'll try to test again with it before sending a PR, right now I do not understand when does podman (3.4.4) set a private label for a volume. A named volume is set with a shared label, a bind mount from the host.. is not even relabeled with podman play kube.

@fulminemizzega
Copy link
Contributor Author

Podman (v4.0.2) (as root) does not set a private label for a volume with play kube. It does not relabel a bind mount, named volumes get a shared label. I'll open a PR to correct the docs.

@rhatdan
Copy link
Member

rhatdan commented Apr 14, 2022

Correct podman play kube has no way of signally in the kubernetes.yaml file how to label content, this is governed by Kubernetes. Kubernetes says some other tool is required to setup the labeling. Since Podman cannot change the YAML file, we need to follow the kubernetes rules.

@rhatdan rhatdan closed this as completed Apr 14, 2022
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 20, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

No branches or pull requests

2 participants