...

SELinux is once again enforcing by default in dom0 and the ndvm, and should be providing comparable protection to what was provided before the jethro merge (including MCS protection of qemu, which is default-confined by MCS in the refpolicy).  If you encounter a problem that you believe is due to SELinux, you can confirm whether SELinux is the culprit by checking /var/log/messages in dom0 for any "avc:  denied" messages and by re-testing with SELinux temporarily in permissive mode by running setenforce 0 in dom0 and/or the ndvm.  If SELinux is the culprit, please either resolve the denial yourself through policy change or post the denials and a description of what you did to trigger them to the openxt group so that someone else can address them.

There are known occasional denials when various daemons try to access a /dev node before udev has labeled it, e.g.

avc:  denied  { read write } for  pid=868 comm="input_server" name="event7" dev="devtmpfs" ino=12719 scontext=system_u:system_r:input_server_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=0

This is due to the fact that devtmpfs creates all device nodes with a single, fixed owner/group/mode and SELinux label initially, to be fixed up by udev later, but userspace may try accessing the node before udev has done so.  Generally this is harmless as well-behaved userspace will retry after udev has handled the node, so we will ultimately dontaudit most if not all of these cases, but we may need to allow specific cases for ill-behaved userspace.  An alternative would be to define name-based type transitions in policy to cause the devtmpfs nodes to be labeled correctly upon creation, but that mechanism is not well-suited to this purpose.

ToDo

Areas for further investigation and improvement wrt SELinux in OpenXT, in no particular order:

...