Versions Compared

Old Version 3

changes.mady.by.user Stephen Smalley

Saved on

compared with

New Version Current

changes.mady.by.user Stephen Smalley

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This page documents the current state of SELinux in OpenXT on the master branch .

As part of the update to jethro, SELinux was switched into permissive mode for dom0 and the ndvm due to breakage.  This is identified by OXT-432.   A number of changes have already been merged to openxt and xenclient-oe to fix SELinux labeling, code, and policy problems.  The currently open pull requests in this area are:

Once these changes are applied, SELinux will again be enforcing by default for and possible areas for improvement.

Status

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 after these changes are merged, 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.

ToDo

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

  • 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)Exercise OpenXT functionality more fully to identify and address any remaining SELinux denials that trigger during normal, legitimate OpenXT usage.
  • 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.Consider updating to the most recent refpolicy release available in the jethro
  • branchPrune 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.
  • 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.

...