Files
xen/tools/flask/policy/modules/xen.te
T
Christopher Clark 2993eca828 xsm: policy hooks to require an IOMMU and interrupt remapping
Isolation of devices passed through to domains usually requires an
active IOMMU. The existing method of requiring an IOMMU is via a Xen
boot parameter ("iommu=force") which will abort boot if an IOMMU is not
available.

More graceful degradation of behaviour when an IOMMU is absent can be
achieved by enabling XSM to perform enforcement of IOMMU requirement.

This patch enables an enforceable XSM policy to specify that an IOMMU is
required for particular domains to access devices and how capable that
IOMMU must be. This allows a Xen system to boot whilst still
ensuring that an IOMMU is active before permitting device use.

Using a XSM policy ensures that the isolation properties remain enforced
even when the large, complex toolstack software changes.

For some hardware platforms interrupt remapping is a strict requirement
for secure isolation. Not all IOMMUs provide interrupt remapping.
The XSM policy can now optionally require interrupt remapping.

The device use hooks now check whether an IOMMU is:
 * Active and securely isolating:
    -- current criteria for this is that interrupt remapping is ok
 * Active but interrupt remapping is not available
 * Not active

This patch also updates the reference XSM policy to use the new
primitives, with policy entries that do not require an active IOMMU.

Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Ross Philipson <ross.philipson@gmail.com>
2017-08-23 17:47:04 +02:00

93 lines
3.0 KiB
Plaintext

################################################################################
#
# Attributes for types
#
# An attribute may be used in a rule as shorthand for all types with that
# attribute.
#
################################################################################
attribute xen_type;
attribute domain_type;
attribute domain_self_type;
attribute domain_target_type;
attribute resource_type;
attribute event_type;
attribute mls_priv;
################################################################################
#
# Types for the initial SIDs
#
# These types are used internally for objects created during Xen startup or for
# devices that have not yet been labeled
#
################################################################################
# The hypervisor itself
type xen_t, xen_type, mls_priv;
# Domain 0
declare_singleton_domain(dom0_t, mls_priv);
# I/O memory (DOMID_IO pseudo-domain)
type domio_t, xen_type;
# Xen heap (DOMID_XEN pseudo-domain)
type domxen_t, xen_type;
# Unlabeled objects
type unlabeled_t, xen_type;
# The XSM/FLASK security server
type security_t, xen_type;
# Unlabeled device resources
# Note: don't allow access to these types directly; see below for how to label
# devices and use that label for allow rules
type irq_t, resource_type;
type ioport_t, resource_type;
type iomem_t, resource_type;
type device_t, resource_type;
# Domain destruction can result in some access checks for actions performed by
# the hypervisor. These should always be allowed.
allow xen_t resource_type : resource { remove_irq remove_ioport remove_iomem };
################################################################################
#
# Policy constraints
#
# Neverallow rules will cause the policy build to fail if an allow rule exists
# that violates the expression. This is used to ensure proper labeling of
# objects.
#
################################################################################
# Domains must be declared using domain_type
neverallow * ~domain_type:domain { create transition };
# Resources must be declared using resource_type
neverallow * ~resource_type:resource { use use_iommu use_iommu_nointremap
use_noiommu };
# Events must use event_type (see create_channel for a template)
neverallow ~event_type *:event bind;
neverallow * ~event_type:event { create send status };
################################################################################
#
# Users and Roles
#
################################################################################
# The object role (object_r) is used for devices, resources, and event channels;
# it does not need to be defined here and should not be used for domains.
# The system user and role are used for utility domains and pseudo-domains. In
# systems where users and roles are not being used for separation, all domains
# can use the system user and role.
gen_user(system_u,, system_r, s0, s0 - mls_systemhigh)
role system_r;
role system_r types { xen_type dom0_t };