SELinux prevents rootless container from using passed device

[faern]

/kind bug

Description

Unable to use a device I pass to my rootless container due to SELinux denying it.

Steps to reproduce the issue:

1. Make sure my device is accessible by my non-root user with udev rules. Here I make sure I own the device. To rule out issues related to the mapping of groups discussed in most other threads about passing devices to containers.

   $ lsusb | grep cafe:4004
   Bus 002 Device 007: ID cafe:4004 Blinkinlabs ICE40 programmer
   
   $ ls -l /dev/bus/usb/002/007
   crw-rw-rw-. 1 faern dialout 189, 134 Sep 25 11:55 /dev/bus/usb/002/007
   

2. Pass the device to a container and try to access it there (I get the exact same error with --group-add keep-groups added):

   $ podman run --rm --device /dev/bus/usb/002/007 -it ubuntu:latest ls -l /dev/bus/usb/002
   ls: cannot access '/dev/bus/usb/002/007': Permission denied
   total 0
   -????????? ? ? ? ?            ? 007
   

3. Check the SELinux audit log:

   type=AVC msg=audit(1664100186.243:5003): avc:  denied  { getattr } for  pid=1368643 comm="ls" path="/dev/bus/usb/002/007" dev="devtmpfs" ino=14869 scontext=system_u:system_r:container_t:s0:c349,c790 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file permissive=0
   

4. Try the same thing with SELinux disabled:

   $ podman run --rm --security-opt label=disable --device /dev/bus/usb/002/007 -it ubuntu:latest ls -l /dev/bus/usb/002
   total 0
   crw-rw-rw-. 1 root nogroup 189, 134 Sep 25 10:00 007
   

Describe the results you received:

SELinux blocking access to devices I own inside containers.

Describe the results you expected:

To be able to have SELinux enabled and access the hardware device inside a rootless container that my non-root user owns and can use without a problem outside of the container.

Additional information you deem important:

I found a similar but closed issue. I added some earlier findings there first. But since it seems old and dead, I create this new issue instead. #9706 (comment).

I found this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1770553. And it talks about:

container-selinux-2.176.0 now has a boolean to allow users to use devices within containers.

Which I traced down to be containers/container-selinux@v2.174.0...v2.175.0. Does podman make use of the new container_use_devices in any way? Is that the issue or is this a red herring completely?

Output of podman version:

Client:       Podman Engine
Version:      4.2.0
API Version:  4.2.0
Go Version:   go1.18.4
Built:        Thu Aug 11 16:42:17 2022
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.27.0
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.0-2.fc36.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.0, commit: '
  cpuUtilization:
    idlePercent: 78.04
    systemPercent: 4.1
    userPercent: 17.86
  cpus: 32
  distribution:
    distribution: fedora
    variant: workstation
    version: "36"
  eventLogger: journald
  hostname: shifty
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.18.18-200.fc36.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 14196977664
  memTotal: 67329413120
  networkBackend: cni
  ociRuntime:
    name: crun
    package: crun-1.5-1.fc36.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.5
      commit: 54ebb8ca8bf7e6ddae2eb919f5b82d1d96863dea
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/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: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-0.2.beta.0.fc36.x86_64
    version: |-
      slirp4netns version 1.2.0-beta.0
      commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 6634475520
  swapTotal: 8589930496
  uptime: 734h 3m 4.00s (Approximately 30.58 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /home/faern/.config/containers/storage.conf
  containerStore:
    number: 18
    paused: 0
    running: 0
    stopped: 18
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/faern/.local/share/containers/storage
  graphRootAllocated: 644228317184
  graphRootUsed: 453298401280
  graphStatus:
    Backing Filesystem: btrfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 53
  runRoot: /run/user/1000/containers
  volumePath: /home/faern/.local/share/containers/storage/volumes
version:
  APIVersion: 4.2.0
  Built: 1660228937
  BuiltTime: Thu Aug 11 16:42:17 2022
  GitCommit: ""
  GoVersion: go1.18.4
  Os: linux
  OsArch: linux/amd64
  Version: 4.2.0

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

$ rpm -q podman
podman-4.2.0-2.fc36.x86_64

$ rpm -q container-selinux
container-selinux-2.190.0-1.fc36.noarch

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)

Yes. I have tried with podman 4.2.0, and the latest as of writing this is 4.2.1. But the changelog for 4.2.1 does not mention devices or SELinux.

The troubleshooting guide talks about devices in question 20 and 35. Neither seem to be SELinux related or helps here.

Additional environment details (AWS, VirtualBox, physical, etc.):

Physical PC

[giuseppe]

have you tried running setsebool container_use_devices=true as root?

[faern]

This works! Wow, thank you! Am I blind or is this option really hidden? I have been searching the web for podman + devices and even that exact SELinux option name for quite a while now and nothing close to this comes up. TIL new stuff about SELinux 🥳

[rhatdan]

We should add this information to the podman run and podman create man page, to make this more discoverable.

[mailinglists35]

I have a block device on host, I can see it and read/write to it in container, but a process in container wants to chown the device node.

how do I assign the user and group ownership to the device inside the container, so that process would not need to issue a chown? it currently shows as brw-rw----. 1 nobody nobody

using podman on oracle linux 9.2

setup like https://www.redhat.com/sysadmin/files-devices-podman

not sure I understand this paragraph from the article, is it that the cause for user nobody? should instead I use the --annotation run.oci.keep_original_groups=1 method instead?

"If you use the --group-add keep-groups call, you cannot set other groups within the container. Instead, the container can only inherit the parent's groups. The reason for this is that Podman requires the setgroups call to set additional groups within the container, and this would lose access to the parent's groups. Giuseppe Scrivanohas proposed two patches to allow setgroups in this situation. This approach is still under discussion. Giuseppe has also opened an issue with the runtime-spec to make this a formal part of the specification and get it into other oci-runtimes like runc, but it also has not merged yet."

my goal is to run the unsupported el9 feature of qemu macos guest, and instead of recompiling I am thinking of running a fedora qemu+libvirt (which can emulate apple) inside a container, also an unsupported el9 libvirt/qemu feature (but it seems to work in red hat openshift for virtualization - how do they do it there? is it it privileged container?)

[rhatdan]

You can't unless the actual UID/GID is mapped in the user namespace via the /etc/subuid and /etc/subgid files.