Description

When running kata-containers with containerd, regardless of having SELinux enabled, SELinux configured, container-selinux package with the container_kvm_t type provided, the VMM / virtiofsd processes are not confined by the container_kvm_t label, and run with the container_runtime_t instead.

Steps to reproduce the issue

1. Have kata-containers set up to be used with containerd and with SELinux enabled

[plugins]
  [plugins.cri]
    enable_selinux = true
    [plugins.cri.containerd]
      [plugins.cri.containerd.runtimes]
        [plugins.cri.containerd.runtimes.kata]
           runtime_type = "io.containerd.kata.v2"
           privileged_without_host_devices = true

2. Ensure you're running on a system that's SELinux capable (using CentOS 8 for my tests here)
3. Create a simple pod

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  runtimeClassName: kata
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

4. Check the SELinux label for the VMM process

$ ps -auxZ | grep cloud-hypervisor
system_u:system_r:container_runtime_t:s0 root 609717 4.0  0.5 2987512 83588 ?    Sl   08:32   0:00 /usr/bin/cloud-hypervisor --api-socket /run/vc/vm/be9d5cbabf440510d58d89fc8a8e77c27e96ddc99709ecaf5ab94c6b6b0d4c89/clh-api.sock

Describe the results you received and expected

The received results show the VMM process is confined by the "container_runtime_t" label, although the expected results are that the VMM process should be confined by the "container_kvm_t" label.

What version of containerd are you using?

containerd github.com/containerd/containerd v1.6.0-beta.3-88-g7fa44fc98 7fa44fc

Any other relevant information

The ability to handle KVM based runtimes with SELinux has been added as
part of d715d00. However, there's a
reasonable chance it's never worked as expected due to a mismatch in the
expectation of how to detect whether the "container_kvm_t" label would
be present in a system.

The approach currently taken to verify whether the type exists is by
inspecing "/etc/selinux/targeted/contexts/customizable_types", which
is provided by the selinux-policy-targeted package and, on a Fedora 35
machine, looks like:

container_file_t
sandbox_file_t
svirt_image_t
svirt_home_t
svirt_sandbox_file_t
virt_content_t
httpd_user_htaccess_t
httpd_user_script_exec_t
httpd_user_rw_content_t
httpd_user_ra_content_t
httpd_user_content_t
git_session_content_t
home_bin_t
user_tty_device_t

The expectation mismatch happens as the "container_kvm_t" file is not
part of the selinux-policy-targeted package but, insteadn, part of the
container-selinux one.

After inspecting the content of the container-selinux package, it seems
the most suitable file to check whether the package used in the distro
provides support for the "container_kvm_t" type is
"/usr/share/containers/selinux/contexts", which has as its content:

process = "system_u:system_r:container_t:s0"
file = "system_u:object_r:container_file_t:s0"
ro_file="system_u:object_r:container_ro_file_t:s0"
kvm_process = "system_u:system_r:container_kvm_t:s0"
init_process = "system_u:system_r:container_init_t:s0"
engine_process = "system_u:system_r:container_engine_t:s0"

With everything said above in mind, I've decided to open an issue for
the container-selinux project,
so they can provide such a file to ease the detection of which types are
provided by the package.

I am also opening a PR to workaround the issue on the containerd side
considering how things are nowadays.

Show configuration if it is related to CRI plugin.

[plugins]
  [plugins.cri]
    enable_selinux = true
    [plugins.cri.containerd]
      [plugins.cri.containerd.runtimes]
        [plugins.cri.containerd.runtimes.kata]
           runtime_type = "io.containerd.kata.v2"
           privileged_without_host_devices = true