This page documents the current state of SELinux in OpenXT on the master branch and possible areas for improvement.

Status

As of commit 68b8751b4fdc9998acbb5a70321f1259923b12ad, 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.

Pending pull requests for known denials:

...

.

...

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

...

• 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.  Also consider changing how modules.conf is managed in the OpenXT metadata (currently a patch to refpolicy; would prefer a complete configuration for OpenXT that replaces refpolicy's default).
• 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.

  Consider updating to the most recent refpolicy release available in the jethro branch

  .

• Switch from a fixed commit for meta-selinux to the new upstream jethro branch.
• 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.