But is this on purpose? I believe cri-o avoids this issue with this bit of code: https://github.com/cri-o/cri-o/blob/6913db94057003374008502da76d070cdf6d3cc5/server/sandbox_run_linux.go#L240-L245

In discussing this with @ibuildthecloud late last week he was under the impression that this failure in containerd/cri when running critest is the result of a deliberate decision. Any pointers?

This patch to containers/container-selinux fixes the problem on Fedora 32:

diff --git a/container.te b/container.te
index 0c7e666..eff4ce6 100644
--- a/container.te
+++ b/container.te
@@ -1091,6 +1091,11 @@ dontaudit container_domain sysctl_type:file write;
 
 allow container_t proc_t:filesystem remount;
 
+gen_require(`
+       attribute unconfined_domain_type;
+')
+allow container_domain unconfined_domain_type:shm r_shm_perms;
+
 # Container kvm - Policy for running kata containers
 container_domain_template(container_kvm)
 typeattribute container_kvm_t container_net_domain;

My reading of https://danwalsh.livejournal.com/74754.html, however, makes me think that this would be Bad ™️

I am still new to this space but am trying to resolve the last remaining critest failure for containerd/cri (containers/container-selinux#98 fixed all but this). I am hopeful that @crosbymichael or @rhatdan might have some feedback on this potential policy patch.