Kubevirt: Allow running VMs with SELinux enabled

[cynepco3hahue]

Currently, environment with enabled selinux cannot run VM

5m 5m 24 virt-handler, node0 Warning SyncFailed virError(Code=1, Domain=10, Message='internal error: process exited while connecting to monitor: libvirt: error : cannot execute binary /usr/local/bin/qemu-system-x86_64: Permission denied')

And it only the beginning, problems that I saw:

• filesystem under container does not have any labels at all, all dirs and files have unlabeled_t context
• files with svirt_tcg_t context must have access to a lot of resources on the system(check Adam post https://adam.younglogic.com/2017/08/selinux-for-kubevirt-on-centos/)

[fabiand]

Are you able to fetch a audit-log, @cynepco3hahue ?

[cynepco3hahue]

@fabiand It almost the same as under Adam blog, but I can re-enable SELinux on my environment and add audit.log

[fabiand]

Please attach it here, then we have everything together - even if you just
copy it from the blog.

[simon3z]

@fabiand given that this issue is critical-urgent I think we should formalize the assignee.

[karmab]

note that now that the code was fully refactored,
issues only happen with pvcs, that is, a vm using a registry disk can boot with selinux.

with pvc, sadly i m not able to grab any avc denials anymore

[fabiand]

Cool.

And that makes sense, because if we are using storage as provided by Kube/OpenShift, then we are covered by the openshift policy.
Just registry containers fall a bit out of the usual pattern.

I'll create a separate issue for those.

[fabiand]

@cynepco3hahue Can you add a test case to check for denials during our test runs?

[fabiand]

I've created two separate issues to track the testcase and the registry disk case. But all in all we seem to be set.

[fabiand]

Correction:

Denials happen with PVCs
No denials happen with registry disks.

Thus we need to keep this bug open.

[cynepco3hahue]

@fabiand I checked AVC denials on OpenShift environment after functional tests run and I do not see any new denials, so looks like all code refactoring solved all SELinux problems

sudo audit2allow -a

#============= dnsmasq_t ==============
allow dnsmasq_t spc_t:dbus send_msg;

I also ran all tests on the environment with enabled SELinux and it passed without failures, I think we can(need) to enable it under our CI.
@karmab Please re-open the issue if you will have additional problems with SELinux

[fabiand]

AWESOME. Thank you.