...
- 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.
- 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.