...

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:

• Exercise OpenXT functionality more fully to identify and address any remaining SELinux denials that trigger during normal, legitimate OpenXT usage.Review the set of policy modules enabled in modules.conf and disable any that are not needed by OpenXT.
• Investigate disabling the unconfined module.  This both removes the unconfined_t domain and locks down various other domains that are otherwise unconfined, thereby making the policy significantly more locked down.  Unfortunately, OpenXT policy does appear to rely on unconfined domains for several of its own domains, so this will require fleshing out those domains.
• Identify the components in dom0 and the ndvm that are at greatest risk of exploitation, and tighten the specific policies for those components.
• Identify specific security goals that OpenXT would like enforced within dom0 and the ndvm, configure the SELinux policy to enforce those goals (if not already), and perform build-time validation of those goals via neverallow rules.  See Android for examples of doing this, e.g. http://kernsec.org/files/lss2014/lss2014_androidtcb_smalley.pdf and http://kernsec.org/files/lss2015/lss2015_selinuxinandroidlollipopandm_smalley.pdf
• Extend MCS protection beyond qemu to other processes associated with specific VMs.
• Prune any unnecessary files from policy and the SELinux userspace from the final images that are not needed for OpenXT production use (especially if not using modular policy on the end system).

• Audit all of the OpenXT policy patches and modules.

• Get the new SELinux userpace release back-ported to the upstream jethro branch, and then switch over to using it.
• Consider adding auditd (requires corresponding ndvm support for forwarding audit records to dom0, possibly using an audit dispatcher plugin).
• Consider how policy is currently managed, both for the target and in the metadata, to see whether it makes sense to support genuine modular policy.  This seems problematic for the end system due to the root filesystem being read-only and potentially measured.  It may only make sense in the build.
• Add automated tests for SELinux enforcing status, labeling of processes and files, and policy, similar to the Android SELinux CTS tests.
• Possibly far-out idea: Consider creating a from-scratch policy for dom0 and the ndvm similar to what we did for Android, and not using refpolicy at all.  Benefits: Minimizes footprint and maximizes security/least privilege, ensures that we fully understand what properties we are getting, allows tailoring to the specifics of OpenXT.  Costs: Requires non-trivial up front development cost and ongoing maintenance cost, along with associated SELinux expertise.