Files
xen/tools/flask/policy/modules/xen.te
T
Daniel P. Smith a0bb0960e5 flask: implement xsm_set_system_active
This commit implements full support for starting the idle domain privileged by
introducing a new flask label xenboot_t which the idle domain is labeled with
at creation.  It then provides the implementation for the XSM hook
xsm_set_system_active to relabel the idle domain to the existing xen_t flask
label.

In the reference flask policy a new macro, xen_build_domain(target), is
introduced for creating policies for dom0less/hyperlaunch allowing the
hypervisor to create and assign the necessary resources for domain
construction.

Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Rahul Singh <rahul.singh@arm.com>
Tested-by: Rahul Singh <rahul.singh@arm.com>
2022-07-04 14:47:00 +02:00

94 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 xenboot_t, xen_type, mls_priv;
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 };