container_kvm_t: cloud-hypervisor can't access /dev/net/tun device
Closed this issue · 5 comments
When running kata-containers on a cluster with SELinux in enforcing mode, using cloud-hypervisor as VMM, I'm getting the following AVC:
type=AVC msg=audit(1638458404.600:6730): avc: denied { open } for pid=188374 comm="vmm" path="/dev/net/tun" dev="devtmpfs" ino=12642 scontext=system_u:system_r:container_kvm_t:s0:c181,c235 tcontext=system_u:object_r:tun_tap_device_t:s0 tclass=chr_file permissive=1
Using the following allow rule has worked this around for me:
[root@centos cri-o]# ausearch -m AVC -ts recent | audit2allow -R
require {
type container_kvm_t;
}
#============= container_kvm_t ==============
corenet_rw_tun_tap_dev(container_kvm_t)
@rhatdan, I am not familiar with providing a patch for the container-selinux myself, but I can do with some guidance. Otherwise, if ou just think it's easier / faster to do it yourself, please, just let me know if the info provided is enough or if there's something else I could do from my side.
You want to allow confined containers to be able to read/write tunnel tap devices? This is not allowed to general containers?
BTW just open an PR this looks simple enought, I just want to make sure you want this access to all kata containers.
BTW just open an PR this looks simple enought, I just want to make sure you want this access to all kata containers.
Let's hold on this a little bit, and let me double-check with the cloud-hypervisor developers to be totally sure on what I'm proposing here. I didn't know, for instance, that this is not allowed to general containers, and that raises a red flag.
Hmm. Of course it's not, that's the reason we slirp4netns is still used, right?
Okay, let me close this one for now and contact the cloud-hypervisor team on how we could solve this on their side as the first thing.