[PATCH 0/5] flask/policy: Updates for Xen 4.8

[PATCH 0/5] flask/policy: Updates for Xen 4.8

[Daniel De Graaf]

The most important patch is the first one, which splits up the XSM
policy into multiple files that can be enabled/disabled to adjust the
policy.  The others are just general cleanup of the policy build and a
better xenstore example.

[PATCH 1/5] flask/policy: split into modules
[PATCH 2/5] flask/policy: move user definitions and constraints into
[PATCH 3/5] flask/policy: Remove unused support for binary modules
[PATCH 4/5] flask/policy: xenstore stubdom policy
[PATCH 5/5] flask/policy: comment out unused xenstore example

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH 1/5] flask/policy: split into modules

[Daniel De Graaf]

This makes it easier to enable or disable parts of the XSM policy.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/Makefile                        |  22 +-
 tools/flask/policy/modules/default_role.te         |   8 +
 tools/flask/policy/modules/dom0.te                 |  74 ++++++
 tools/flask/policy/modules/domU.te                 |  28 +++
 tools/flask/policy/modules/guest_features.te       |  31 +++
 tools/flask/policy/modules/isolated_domU.te        |   7 +
 tools/flask/policy/modules/modules.conf            |  37 +++
 tools/flask/policy/modules/nic_dev.te              |  14 ++
 tools/flask/policy/modules/nomigrate.te            |   8 +
 tools/flask/policy/modules/prot_domU.te            |  13 +
 .../policy/{policy/modules/xen => modules}/xen.if  |   0
 tools/flask/policy/modules/xen.te                  |  84 +++++++
 tools/flask/policy/policy/modules.conf             |  15 --
 tools/flask/policy/policy/modules/xen/xen.te       | 272 ---------------------
 14 files changed, 311 insertions(+), 302 deletions(-)
 create mode 100644 tools/flask/policy/modules/default_role.te
 create mode 100644 tools/flask/policy/modules/dom0.te
 create mode 100644 tools/flask/policy/modules/domU.te
 create mode 100644 tools/flask/policy/modules/guest_features.te
 create mode 100644 tools/flask/policy/modules/isolated_domU.te
 create mode 100644 tools/flask/policy/modules/modules.conf
 create mode 100644 tools/flask/policy/modules/nic_dev.te
 create mode 100644 tools/flask/policy/modules/nomigrate.te
 create mode 100644 tools/flask/policy/modules/prot_domU.te
 rename tools/flask/policy/{policy/modules/xen => modules}/xen.if (100%)
 create mode 100644 tools/flask/policy/modules/xen.te
 delete mode 100644 tools/flask/policy/policy/modules.conf
 delete mode 100644 tools/flask/policy/policy/modules/xen/xen.te

diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index 4be921c..b2c2d06 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -37,7 +37,7 @@ POLICY_VER_LIST_HV = 24 30
 
 # policy source layout
 POLDIR := policy
-MODDIR := $(POLDIR)/modules
+MODDIR := modules
 
 # Classes and access vectors defined in the hypervisor. Changes to these require
 # a recompile of both the hypervisor and security policy.
@@ -60,7 +60,7 @@ DEV_OCONS := $(POLDIR)/device_contexts
 
 # config file paths
 GLOBALTUN := $(POLDIR)/global_tunables
-MOD_CONF := $(POLDIR)/modules.conf
+MOD_CONF := $(MODDIR)/modules.conf
 
 # checkpolicy can use the #line directives provided by -s for error reporting:
 M4PARAM := -D self_contained_policy -s
@@ -84,22 +84,14 @@ endif
 M4PARAM += -D mls_num_sens=$(MLS_SENS) -D mls_num_cats=$(MLS_CATS)
 
 
-# Find modules
-ALL_LAYERS := $(filter-out $(MODDIR)/CVS,$(shell find $(wildcard $(MODDIR)/*) -maxdepth 0 -type d))
-
-# sort here since it removes duplicates, which can happen
-# when a generated file is already generated
-DETECTED_MODS := $(sort $(foreach dir,$(ALL_LAYERS),$(wildcard $(dir)/*.te)))
-
 # modules.conf setting for policy configuration
 MODENABLED := on
 
 # extract settings from modules.conf
-ENABLED_MODS := $(foreach mod,$(shell awk '/^[ \t]*[a-z]/{ if ($$3 == "$(MODENABLED)") print $$1 }' $(MOD_CONF) 2> /dev/null),$(subst ./,,$(shell find -iname $(mod).te)))
-
-ALL_MODULES := $(filter $(ENABLED_MODS),$(DETECTED_MODS))
+ENABLED_LIST := $(shell awk '/^[ \t]*[a-z]/{ if ($$3 == "$(MODENABLED)") print $$1 }' $(MOD_CONF) 2> /dev/null)
 
-ALL_INTERFACES := $(ALL_MODULES:.te=.if)
+ALL_MODULES := $(foreach mod,$(ENABLED_LIST),$(MODDIR)/$(mod).te)
+ALL_INTERFACES := $(wildcard $(ALL_MODULES:.te=.if))
 
 # The order of these files is important
 POLICY_SECTIONS := $(SECCLASS) $(ISID_DECLS) $(AVS)
@@ -118,8 +110,8 @@ install: $(POLICY_FILENAME)
 $(POLICY_FILENAME): policy.conf
 	$(CHECKPOLICY) $(CHECKPOLICY_PARAM) $^ -o $@
 
-policy.conf: $(POLICY_SECTIONS)
-	$(M4) $(M4PARAM) $^ > $@
+policy.conf: $(POLICY_SECTIONS) $(MOD_CONF)
+	$(M4) $(M4PARAM) $(POLICY_SECTIONS) > $@
 
 clean:
 	$(RM) tmp policy.conf $(POLICY_FILENAME)
diff --git a/tools/flask/policy/modules/default_role.te b/tools/flask/policy/modules/default_role.te
new file mode 100644
index 0000000..74f870f
--- /dev/null
+++ b/tools/flask/policy/modules/default_role.te
@@ -0,0 +1,8 @@
+# Allow all domains to use system_r so that systems that are not using the
+# user/role separation feature will work properly.
+role system_r types domain_type;
+
+# The vm role is used as part of user separation.  Allow all domain types to use
+# this role except dom0.
+role vm_r;
+role vm_r types { domain_type -dom0_t };
diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
new file mode 100644
index 0000000..dd4d7dd
--- /dev/null
+++ b/tools/flask/policy/modules/dom0.te
@@ -0,0 +1,74 @@
+################################################################################
+#
+# Allow dom0 access to all sysctls, devices, and the security server.
+#
+# While this could be written more briefly using wildcards, the permissions are
+# listed out to make removing specific permissions simpler.
+#
+################################################################################
+allow dom0_t xen_t:xen {
+	settime tbufcontrol readconsole clearconsole perfcontrol mtrr_add
+	mtrr_del mtrr_read microcode physinfo quirk writeconsole readapic
+	writeapic privprofile nonprivprofile kexec firmware sleep frequency
+	getidle debug getcpuinfo heap pm_op mca_op lockprof cpupool_op tmem_op
+	tmem_control getscheduler setscheduler
+};
+allow dom0_t xen_t:xen2 {
+	resource_op psr_cmt_op psr_cat_op pmu_ctrl get_symbol
+	get_cpu_levelling_caps get_cpu_featureset xsplice_op
+};
+
+# Allow dom0 to use all XENVER_ subops that have checks.
+# Note that dom0 is part of domain_type so this has duplicates.
+allow dom0_t xen_t:version {
+	xen_extraversion xen_compile_info xen_capabilities
+	xen_changeset xen_pagesize xen_guest_handle xen_commandline
+	xen_build_id
+};
+
+allow dom0_t xen_t:mmu memorymap;
+
+# Allow dom0 to use these domctls on itself. For domctls acting on other
+# domains, see the definitions of create_domain and manage_domain.
+allow dom0_t dom0_t:domain {
+	setvcpucontext max_vcpus setaffinity getaffinity getscheduler
+	getdomaininfo getvcpuinfo getvcpucontext setdomainmaxmem setdomainhandle
+	setdebugging hypercall settime setaddrsize getaddrsize trigger
+	getextvcpucontext setextvcpucontext getvcpuextstate setvcpuextstate
+	getpodtarget setpodtarget set_misc_info set_virq_handler
+};
+allow dom0_t dom0_t:domain2 {
+	set_cpuid gettsc settsc setscheduler set_max_evtchn set_vnumainfo
+	get_vnumainfo psr_cmt_op psr_cat_op
+};
+allow dom0_t dom0_t:resource { add remove };
+
+# These permissions allow using the FLASK security server to compute access
+# checks locally, which could be used by a domain or service (such as xenstore)
+# that does not have its own security server to make access decisions based on
+# Xen's security policy.
+allow dom0_t security_t:security {
+	compute_av compute_create compute_member compute_relabel compute_user
+};
+
+# Allow string/SID conversions (for "xl list -Z" and similar)
+allow dom0_t security_t:security check_context;
+
+# Allow flask-label-pci to add and change labels
+allow dom0_t security_t:security { add_ocontext del_ocontext };
+
+# Allow performance parameters of the security server to be tweaked
+allow dom0_t security_t:security setsecparam;
+
+# Allow changing the security policy
+allow dom0_t security_t:security { load_policy setenforce setbool };
+
+# Audit policy change events even when they are allowed
+auditallow dom0_t security_t:security { load_policy setenforce setbool };
+
+admin_device(dom0_t, device_t)
+admin_device(dom0_t, irq_t)
+admin_device(dom0_t, ioport_t)
+admin_device(dom0_t, iomem_t)
+
+domain_comms(dom0_t, dom0_t)
diff --git a/tools/flask/policy/modules/domU.te b/tools/flask/policy/modules/domU.te
new file mode 100644
index 0000000..b77df29
--- /dev/null
+++ b/tools/flask/policy/modules/domU.te
@@ -0,0 +1,28 @@
+###############################################################################
+#
+# Domain creation
+#
+###############################################################################
+
+declare_domain(domU_t)
+domain_self_comms(domU_t)
+create_domain(dom0_t, domU_t)
+manage_domain(dom0_t, domU_t)
+domain_comms(dom0_t, domU_t)
+domain_comms(domU_t, domU_t)
+migrate_domain_out(dom0_t, domU_t)
+domain_self_comms(domU_t)
+
+# Device model for domU_t.  You can define distinct types for device models for
+# domains of other types, or add more make_device_model lines for this type.
+declare_domain(dm_dom_t)
+create_domain(dom0_t, dm_dom_t)
+manage_domain(dom0_t, dm_dom_t)
+domain_comms(dom0_t, dm_dom_t)
+make_device_model(dom0_t, dm_dom_t, domU_t)
+
+# This is required for PCI (or other device) passthrough
+delegate_devices(dom0_t, domU_t)
+
+# Both of these domain types can be created using the default (system) role
+role system_r types { domU_t dm_dom_t };
diff --git a/tools/flask/policy/modules/guest_features.te b/tools/flask/policy/modules/guest_features.te
new file mode 100644
index 0000000..9ac9780
--- /dev/null
+++ b/tools/flask/policy/modules/guest_features.te
@@ -0,0 +1,31 @@
+# Allow all domains to use (unprivileged parts of) the tmem hypercall
+allow domain_type xen_t:xen tmem_op;
+
+# Allow all domains to use PMU (but not to change its settings --- that's what
+# pmu_ctrl is for)
+allow domain_type xen_t:xen2 pmu_use;
+
+# Allow guest console output to the serial console.  This is used by PV Linux
+# and stub domains for early boot output, so don't audit even when we deny it.
+# Without XSM, this is enabled only if the Xen was compiled in debug mode.
+gen_bool(guest_writeconsole, true)
+if (guest_writeconsole) {
+	allow domain_type xen_t : xen writeconsole;
+} else {
+	dontaudit domain_type xen_t : xen writeconsole;
+}
+
+# For normal guests, allow all queries except XENVER_commandline.
+allow domain_type xen_t:version {
+    xen_extraversion xen_compile_info xen_capabilities
+    xen_changeset xen_pagesize xen_guest_handle
+};
+
+# Version queries don't need auditing when denied.  They can be
+# encountered in normal operation by xl or by reading sysfs files in
+# Linux, so without this they will show up in the logs.  Since these
+# operations return valid responses (like "denied"), hiding the denials
+# should not break anything.
+dontaudit domain_type xen_t:version {
+	xen_commandline xen_build_id
+};
diff --git a/tools/flask/policy/modules/isolated_domU.te b/tools/flask/policy/modules/isolated_domU.te
new file mode 100644
index 0000000..4ee7689
--- /dev/null
+++ b/tools/flask/policy/modules/isolated_domU.te
@@ -0,0 +1,7 @@
+declare_domain(isolated_domU_t)
+create_domain(dom0_t, isolated_domU_t)
+manage_domain(dom0_t, isolated_domU_t)
+domain_comms(dom0_t, isolated_domU_t)
+migrate_domain_out(dom0_t, isolated_domU_t)
+domain_self_comms(isolated_domU_t)
+
diff --git a/tools/flask/policy/modules/modules.conf b/tools/flask/policy/modules/modules.conf
new file mode 100644
index 0000000..5a1d905
--- /dev/null
+++ b/tools/flask/policy/modules/modules.conf
@@ -0,0 +1,37 @@
+#
+# This file contains a listing of available modules.
+#
+# To prevent a module from  being used in policy creation, set the module name
+# to "off"; otherwise, set the module name on "on".
+#
+# The order the modules appear in this file is the order they will be parsed;
+# this can be important if you plan to use types defined in one file in another.
+#
+
+# Basic types and classes for the Xen hypervisor.  This module is required.
+xen = on
+
+# Permissions for domain 0.  Most of these are required to boot.
+dom0 = on
+
+# Allow all domains the ability to use access-controlled features and hypercalls
+# that are not restricted when XSM is disabled.
+guest_features = on
+
+# The default domain type (domU_t) and its device model (dm_dom_t).  The domain
+# is created and managed by dom0_t, and has no special restrictions.
+#
+# This is required if you want to be able to create domains without specifying
+# their XSM label in the configuration.
+domU = on
+
+# Example types with restrictions
+isolated_domU = on
+prot_domU = on
+nomigrate = on
+
+# Example device policy.  Also see policy/device_contexts.
+nic_dev = on
+
+# Example roles.  Also see policy/users.
+default_role = on
diff --git a/tools/flask/policy/modules/nic_dev.te b/tools/flask/policy/modules/nic_dev.te
new file mode 100644
index 0000000..e0484af
--- /dev/null
+++ b/tools/flask/policy/modules/nic_dev.te
@@ -0,0 +1,14 @@
+###############################################################################
+#
+# Device delegation
+#
+# This requires that the device be labeled with a type defined here.  You can
+# use flask-label-pci to dynamically label devices on each boot or define the
+# labels statically in tools/flask/policy/policy/device_contexts
+#
+###############################################################################
+
+type nic_dev_t, resource_type;
+
+admin_device(dom0_t, nic_dev_t)
+use_device(domU_t, nic_dev_t)
diff --git a/tools/flask/policy/modules/nomigrate.te b/tools/flask/policy/modules/nomigrate.te
new file mode 100644
index 0000000..5b56caf
--- /dev/null
+++ b/tools/flask/policy/modules/nomigrate.te
@@ -0,0 +1,8 @@
+# Domains of type nomigrate_t must be built via the nomigrate_t_building label;
+# once built, dom0 cannot read their memory.
+declare_domain(nomigrate_t)
+declare_build_label(nomigrate_t)
+create_domain_build_label(dom0_t, nomigrate_t)
+manage_domain(dom0_t, nomigrate_t)
+domain_comms(dom0_t, nomigrate_t)
+domain_self_comms(nomigrate_t)
diff --git a/tools/flask/policy/modules/prot_domU.te b/tools/flask/policy/modules/prot_domU.te
new file mode 100644
index 0000000..a7c012c
--- /dev/null
+++ b/tools/flask/policy/modules/prot_domU.te
@@ -0,0 +1,13 @@
+# This is an alternative to nomigrate_t: a policy boolean controls the ability
+# to create or migrate a domain of type prot_domU_t.  If disabled, dom0 cannot
+# map memory belonging to those domains.
+gen_bool(prot_doms_locked, false)
+declare_domain(prot_domU_t)
+if (!prot_doms_locked) {
+	create_domain(dom0_t, prot_domU_t)
+	migrate_domain_out(dom0_t, prot_domU_t)
+}
+domain_comms(dom0_t, prot_domU_t)
+domain_comms(domU_t, prot_domU_t)
+domain_comms(prot_domU_t, prot_domU_t)
+domain_self_comms(prot_domU_t)
diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/modules/xen.if
similarity index 100%
rename from tools/flask/policy/policy/modules/xen/xen.if
rename to tools/flask/policy/modules/xen.if
diff --git a/tools/flask/policy/modules/xen.te b/tools/flask/policy/modules/xen.te
new file mode 100644
index 0000000..f374dc5
--- /dev/null
+++ b/tools/flask/policy/modules/xen.te
@@ -0,0 +1,84 @@
+################################################################################
+#
+# 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;
+
+################################################################################
+#
+# 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;
+
+# Events must use event_type (see create_channel for a template)
+neverallow ~event_type *:event bind;
+neverallow * ~event_type:event { create send status };
+
+################################################################################
+#
+# 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 role is used for utility domains and pseudo-domains.  If roles are
+# not being used for separation, all domains can use the system role.
+role system_r;
+role system_r types { xen_type dom0_t };
diff --git a/tools/flask/policy/policy/modules.conf b/tools/flask/policy/policy/modules.conf
deleted file mode 100644
index 8043974..0000000
--- a/tools/flask/policy/policy/modules.conf
+++ /dev/null
@@ -1,15 +0,0 @@
-#
-# This file contains a listing of available modules.
-# To prevent a module from  being used in policy
-# creation, set the module name to "off" otherwise
-# set the module name on "on".
-#
-
-# Layer: xen
-# Module: xen
-# Required in base
-#
-# Policy for xen.
-# 
-xen = on
-
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
deleted file mode 100644
index 0b1c955..0000000
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ /dev/null
@@ -1,272 +0,0 @@
-################################################################################
-#
-# 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;
-
-################################################################################
-#
-# Allow dom0 access to all sysctls, devices, and the security server.
-#
-# While this could be written more briefly using wildcards, the permissions are
-# listed out to make removing specific permissions simpler.
-#
-################################################################################
-allow dom0_t xen_t:xen {
-	settime tbufcontrol readconsole clearconsole perfcontrol mtrr_add
-	mtrr_del mtrr_read microcode physinfo quirk writeconsole readapic
-	writeapic privprofile nonprivprofile kexec firmware sleep frequency
-	getidle debug getcpuinfo heap pm_op mca_op lockprof cpupool_op tmem_op
-	tmem_control getscheduler setscheduler
-};
-allow dom0_t xen_t:xen2 {
-    resource_op
-    psr_cmt_op
-    psr_cat_op
-};
-allow dom0_t xen_t:xen2 {
-    pmu_ctrl
-    get_symbol
-    get_cpu_levelling_caps
-    get_cpu_featureset
-    xsplice_op
-};
-
-# Allow dom0 to use all XENVER_ subops that have checks.
-# Note that dom0 is part of domain_type so this has duplicates.
-allow dom0_t xen_t:version {
-    xen_extraversion xen_compile_info xen_capabilities
-    xen_changeset xen_pagesize xen_guest_handle xen_commandline
-    xen_build_id
-};
-
-allow dom0_t xen_t:mmu memorymap;
-
-# Allow dom0 to use these domctls on itself. For domctls acting on other
-# domains, see the definitions of create_domain and manage_domain.
-allow dom0_t dom0_t:domain {
-	setvcpucontext max_vcpus setaffinity getaffinity getscheduler
-	getdomaininfo getvcpuinfo getvcpucontext setdomainmaxmem setdomainhandle
-	setdebugging hypercall settime setaddrsize getaddrsize trigger
-	getextvcpucontext setextvcpucontext getvcpuextstate setvcpuextstate
-	getpodtarget setpodtarget set_misc_info set_virq_handler
-};
-allow dom0_t dom0_t:domain2 {
-	set_cpuid gettsc settsc setscheduler set_max_evtchn set_vnumainfo
-	get_vnumainfo psr_cmt_op psr_cat_op
-};
-allow dom0_t dom0_t:resource { add remove };
-
-# These permissions allow using the FLASK security server to compute access
-# checks locally, which could be used by a domain or service (such as xenstore)
-# that does not have its own security server to make access decisions based on
-# Xen's security policy.
-allow dom0_t security_t:security {
-	compute_av compute_create compute_member compute_relabel compute_user
-};
-
-# Allow string/SID conversions (for "xl list -Z" and similar)
-allow dom0_t security_t:security check_context;
-
-# Allow flask-label-pci to add and change labels
-allow dom0_t security_t:security { add_ocontext del_ocontext };
-
-# Allow performance parameters of the security server to be tweaked
-allow dom0_t security_t:security setsecparam;
-
-# Allow changing the security policy
-allow dom0_t security_t:security { load_policy setenforce setbool };
-
-# Audit policy change events even when they are allowed
-auditallow dom0_t security_t:security { load_policy setenforce setbool };
-
-admin_device(dom0_t, device_t)
-admin_device(dom0_t, irq_t)
-admin_device(dom0_t, ioport_t)
-admin_device(dom0_t, iomem_t)
-
-domain_comms(dom0_t, dom0_t)
-
-# Allow all domains to use (unprivileged parts of) the tmem hypercall
-allow domain_type xen_t:xen tmem_op;
-
-# Allow guest console output to the serial console.  This is used by PV Linux
-# and stub domains for early boot output, so don't audit even when we deny it.
-# Without XSM, this is enabled only if the Xen was compiled in debug mode.
-gen_bool(guest_writeconsole, true)
-if (guest_writeconsole) {
-	allow domain_type xen_t : xen writeconsole;
-} else {
-	dontaudit domain_type xen_t : xen writeconsole;
-}
-
-# Allow all domains to use PMU (but not to change its settings --- that's what
-# pmu_ctrl is for)
-allow domain_type xen_t:xen2 pmu_use;
-
-# For normal guests all possible except XENVER_commandline.
-allow domain_type xen_t:version {
-    xen_extraversion xen_compile_info xen_capabilities
-    xen_changeset xen_pagesize xen_guest_handle
-};
-
-# These queries don't need auditing when denied.  They can be
-# encountered in normal operation by xl or by reading sysfs files in
-# Linux, so without this they will show up in the logs.  Since these
-# operations return valid responses (like "denied"), hiding the denials
-# should not break anything.
-dontaudit domain_type xen_t:version {
-    xen_commandline xen_build_id
-};
-
-###############################################################################
-#
-# Domain creation
-#
-###############################################################################
-
-declare_domain(domU_t)
-domain_self_comms(domU_t)
-create_domain(dom0_t, domU_t)
-manage_domain(dom0_t, domU_t)
-domain_comms(dom0_t, domU_t)
-domain_comms(domU_t, domU_t)
-migrate_domain_out(dom0_t, domU_t)
-domain_self_comms(domU_t)
-
-declare_domain(isolated_domU_t)
-create_domain(dom0_t, isolated_domU_t)
-manage_domain(dom0_t, isolated_domU_t)
-domain_comms(dom0_t, isolated_domU_t)
-migrate_domain_out(dom0_t, isolated_domU_t)
-domain_self_comms(isolated_domU_t)
-
-# Declare a boolean that denies creation of prot_domU_t domains
-gen_bool(prot_doms_locked, false)
-declare_domain(prot_domU_t)
-if (!prot_doms_locked) {
-	create_domain(dom0_t, prot_domU_t)
-	migrate_domain_out(dom0_t, prot_domU_t)
-}
-domain_comms(dom0_t, prot_domU_t)
-domain_comms(domU_t, prot_domU_t)
-domain_comms(prot_domU_t, prot_domU_t)
-domain_self_comms(prot_domU_t)
-
-# Device model for domU_t.  You can define distinct types for device models for
-# domains of other types, or add more make_device_model lines for this type.
-declare_domain(dm_dom_t)
-create_domain(dom0_t, dm_dom_t)
-manage_domain(dom0_t, dm_dom_t)
-domain_comms(dom0_t, dm_dom_t)
-make_device_model(dom0_t, dm_dom_t, domU_t)
-
-# nomigrate_t must be built via the nomigrate_t_building label; once built,
-# dom0 cannot read its memory.
-declare_domain(nomigrate_t)
-declare_build_label(nomigrate_t)
-create_domain_build_label(dom0_t, nomigrate_t)
-manage_domain(dom0_t, nomigrate_t)
-domain_comms(dom0_t, nomigrate_t)
-domain_self_comms(nomigrate_t)
-
-###############################################################################
-#
-# Device delegation
-#
-# This requires that the device be labeled with a type defined here.  You can
-# use flask-label-pci to dynamically label devices on each boot or define the
-# labels statically in tools/flask/policy/policy/device_contexts
-#
-###############################################################################
-
-type nic_dev_t, resource_type;
-
-admin_device(dom0_t, nic_dev_t)
-use_device(domU_t, nic_dev_t)
-
-delegate_devices(dom0_t, domU_t)
-
-################################################################################
-#
-# 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;
-
-# Events must use event_type (see create_channel for a template)
-neverallow ~event_type *:event bind;
-neverallow * ~event_type:event { create send status };
-
-################################################################################
-#
-# 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 role is used for utility domains and pseudo-domains
-role system_r;
-role system_r types { xen_type domain_type };
-# If you want to prevent domUs from being placed in system_r:
-##role system_r types { xen_type dom0_t };
-
-# The vm role is used for customer virtual machines
-role vm_r;
-role vm_r types { domain_type -dom0_t };
-- 
2.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 1/5] flask/policy: split into modules

[Konrad Rzeszutek Wilk]

On Mon, May 23, 2016 at 11:05:29AM -0400, Daniel De Graaf wrote:
> This makes it easier to enable or disable parts of the XSM policy.
> 

Hey Daniel,

I am no expert on this so please take it with a grain of salt.

.. snip..
> diff --git a/tools/flask/policy/modules/default_role.te b/tools/flask/policy/modules/default_role.te
> new file mode 100644
> index 0000000..74f870f
> --- /dev/null
> +++ b/tools/flask/policy/modules/default_role.te
> @@ -0,0 +1,8 @@
> +# Allow all domains to use system_r so that systems that are not using the
> +# user/role separation feature will work properly.
> +role system_r types domain_type;

In the 'original' code it also had : xen_type :

266 role system_r types { xen_type domain_type };                                   

Is this change done on purpose? Reading the xen.te it describes the 'system_r' as:
 "The system role is used for utility domains and pseudo-domains                "

which is .. confusing. What is an utility domain? Pseudo-domain?

[Looking in the new xen.te I see that it has the same syntax]
> +
> +# The vm role is used as part of user separation.  Allow all domain types to use
> +# this role except dom0.
> +role vm_r;
> +role vm_r types { domain_type -dom0_t };
> diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
> new file mode 100644
> index 0000000..dd4d7dd
> --- /dev/null
> +++ b/tools/flask/policy/modules/dom0.te
> @@ -0,0 +1,74 @@
> +################################################################################
> +#
> +# Allow dom0 access to all sysctls, devices, and the security server.
> +#
> +# While this could be written more briefly using wildcards, the permissions are
> +# listed out to make removing specific permissions simpler.
> +#
> +################################################################################
> +allow dom0_t xen_t:xen {
> +	settime tbufcontrol readconsole clearconsole perfcontrol mtrr_add
> +	mtrr_del mtrr_read microcode physinfo quirk writeconsole readapic
> +	writeapic privprofile nonprivprofile kexec firmware sleep frequency
> +	getidle debug getcpuinfo heap pm_op mca_op lockprof cpupool_op tmem_op
> +	tmem_control getscheduler setscheduler
> +};
> +allow dom0_t xen_t:xen2 {
> +	resource_op psr_cmt_op psr_cat_op pmu_ctrl get_symbol
> +	get_cpu_levelling_caps get_cpu_featureset xsplice_op

Hehe. livepatch_op now :-)

.. giant snip...

> diff --git a/tools/flask/policy/modules/xen.te b/tools/flask/policy/modules/xen.te
> new file mode 100644
> index 0000000..f374dc5
> --- /dev/null
> +++ b/tools/flask/policy/modules/xen.te
.. snip..

> +################################################################################
> +#
> +# 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 role is used for utility domains and pseudo-domains.  If roles are
> +# not being used for separation, all domains can use the system role.
> +role system_r;
> +role system_r types { xen_type dom0_t };

Right here it is back again.

Is the 'default_role' neccessary then?


I've looked at the original xen.te and them splitting out to individual and there were no
missing copy-n-paste (except the above 'default_role.te' which I am not
clear about).

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 1/5] flask/policy: split into modules

[Daniel De Graaf]

On 06/07/2016 03:22 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, May 23, 2016 at 11:05:29AM -0400, Daniel De Graaf wrote:
>> This makes it easier to enable or disable parts of the XSM policy.
>>
>
> Hey Daniel,
>
> I am no expert on this so please take it with a grain of salt.

That can actually be helpful to spot documentation problems :)

> .. snip..
>> diff --git a/tools/flask/policy/modules/default_role.te b/tools/flask/policy/modules/default_role.te
>> new file mode 100644
>> index 0000000..74f870f
>> --- /dev/null
>> +++ b/tools/flask/policy/modules/default_role.te
>> @@ -0,0 +1,8 @@
>> +# Allow all domains to use system_r so that systems that are not using the
>> +# user/role separation feature will work properly.
>> +role system_r types domain_type;
>
> In the 'original' code it also had : xen_type :
>
> 266 role system_r types { xen_type domain_type };
>
> Is this change done on purpose? Reading the xen.te it describes the 'system_r' as:
>  "The system role is used for utility domains and pseudo-domains                "
>
> which is .. confusing. What is an utility domain? Pseudo-domain?

Utility domains would be a domain that is not actually a part of a guest,
such as xenstore, vtpm-manager, and disaggregated components of dom0.

Pseudo-domain is the term used here to refer to DOMID_XEN and DOMID_IO.
Is there a better name for this?

> [Looking in the new xen.te I see that it has the same syntax]
>> +
>> +# The vm role is used as part of user separation.  Allow all domain types to use
>> +# this role except dom0.
>> +role vm_r;
>> +role vm_r types { domain_type -dom0_t };
>> diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
>> new file mode 100644
>> index 0000000..dd4d7dd
>> --- /dev/null
>> +++ b/tools/flask/policy/modules/dom0.te
>> @@ -0,0 +1,74 @@
>> +################################################################################
>> +#
>> +# Allow dom0 access to all sysctls, devices, and the security server.
>> +#
>> +# While this could be written more briefly using wildcards, the permissions are
>> +# listed out to make removing specific permissions simpler.
>> +#
>> +################################################################################
>> +allow dom0_t xen_t:xen {
>> +	settime tbufcontrol readconsole clearconsole perfcontrol mtrr_add
>> +	mtrr_del mtrr_read microcode physinfo quirk writeconsole readapic
>> +	writeapic privprofile nonprivprofile kexec firmware sleep frequency
>> +	getidle debug getcpuinfo heap pm_op mca_op lockprof cpupool_op tmem_op
>> +	tmem_control getscheduler setscheduler
>> +};
>> +allow dom0_t xen_t:xen2 {
>> +	resource_op psr_cmt_op psr_cat_op pmu_ctrl get_symbol
>> +	get_cpu_levelling_caps get_cpu_featureset xsplice_op
>
> Hehe. livepatch_op now :-)
>

I have a corrected series that also has some other pending hypervisor
patches, which I can post whenever the 4.8 merging window is fully
open.

> .. giant snip...
>
>> diff --git a/tools/flask/policy/modules/xen.te b/tools/flask/policy/modules/xen.te
>> new file mode 100644
>> index 0000000..f374dc5
>> --- /dev/null
>> +++ b/tools/flask/policy/modules/xen.te
> .. snip..
>
>> +################################################################################
>> +#
>> +# 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 role is used for utility domains and pseudo-domains.  If roles are
>> +# not being used for separation, all domains can use the system role.
>> +role system_r;
>> +role system_r types { xen_type dom0_t };
>
> Right here it is back again.
>
> Is the 'default_role' neccessary then?

Specifying some role is necessary to create a valid security label
(which is a user:role:type tuple).

The line in xen.te only allows the pseudo-domains and dom0 to use
system_r; this is a useful minimum, if you are going to place any
actual guests in another role.  If you include default_role.te,
then this expands to allowing all domains to use system_r.

I could split the default_role extraction into a separate patch if
you think this explanation belongs in a commit message.

> I've looked at the original xen.te and them splitting out to individual and there were no
> missing copy-n-paste (except the above 'default_role.te' which I am not
> clear about).
>
> Thanks!
>


-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 1/5] flask/policy: split into modules

[Konrad Rzeszutek Wilk]

On Tue, Jun 07, 2016 at 03:39:59PM -0400, Daniel De Graaf wrote:
> On 06/07/2016 03:22 PM, Konrad Rzeszutek Wilk wrote:
> >On Mon, May 23, 2016 at 11:05:29AM -0400, Daniel De Graaf wrote:
> >>This makes it easier to enable or disable parts of the XSM policy.
> >>
> >
> >Hey Daniel,
> >
> >I am no expert on this so please take it with a grain of salt.
> 
> That can actually be helpful to spot documentation problems :)
> 
> >.. snip..
> >>diff --git a/tools/flask/policy/modules/default_role.te b/tools/flask/policy/modules/default_role.te
> >>new file mode 100644
> >>index 0000000..74f870f
> >>--- /dev/null
> >>+++ b/tools/flask/policy/modules/default_role.te
> >>@@ -0,0 +1,8 @@
> >>+# Allow all domains to use system_r so that systems that are not using the
> >>+# user/role separation feature will work properly.
> >>+role system_r types domain_type;
> >
> >In the 'original' code it also had : xen_type :
> >
> >266 role system_r types { xen_type domain_type };
> >
> >Is this change done on purpose? Reading the xen.te it describes the 'system_r' as:
> > "The system role is used for utility domains and pseudo-domains                "
> >
> >which is .. confusing. What is an utility domain? Pseudo-domain?
> 
> Utility domains would be a domain that is not actually a part of a guest,
> such as xenstore, vtpm-manager, and disaggregated components of dom0.

Ah, stubdomains!

Could there be an s/utility domain/utility domain (stubdomains)/ ?

> 
> Pseudo-domain is the term used here to refer to DOMID_XEN and DOMID_IO.
> Is there a better name for this?

Yes pls. That way it is easier to do a grep and find what it can refere to.

> 
> >[Looking in the new xen.te I see that it has the same syntax]
> >>+
> >>+# The vm role is used as part of user separation.  Allow all domain types to use
> >>+# this role except dom0.
> >>+role vm_r;
> >>+role vm_r types { domain_type -dom0_t };
> >>diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
> >>new file mode 100644
> >>index 0000000..dd4d7dd
> >>--- /dev/null
> >>+++ b/tools/flask/policy/modules/dom0.te
> >>@@ -0,0 +1,74 @@
> >>+################################################################################
> >>+#
> >>+# Allow dom0 access to all sysctls, devices, and the security server.
> >>+#
> >>+# While this could be written more briefly using wildcards, the permissions are
> >>+# listed out to make removing specific permissions simpler.
> >>+#
> >>+################################################################################
> >>+allow dom0_t xen_t:xen {
> >>+	settime tbufcontrol readconsole clearconsole perfcontrol mtrr_add
> >>+	mtrr_del mtrr_read microcode physinfo quirk writeconsole readapic
> >>+	writeapic privprofile nonprivprofile kexec firmware sleep frequency
> >>+	getidle debug getcpuinfo heap pm_op mca_op lockprof cpupool_op tmem_op
> >>+	tmem_control getscheduler setscheduler
> >>+};
> >>+allow dom0_t xen_t:xen2 {
> >>+	resource_op psr_cmt_op psr_cat_op pmu_ctrl get_symbol
> >>+	get_cpu_levelling_caps get_cpu_featureset xsplice_op
> >
> >Hehe. livepatch_op now :-)
> >
> 
> I have a corrected series that also has some other pending hypervisor
> patches, which I can post whenever the 4.8 merging window is fully
> open.

/me nods.
> 
> >.. giant snip...
> >
> >>diff --git a/tools/flask/policy/modules/xen.te b/tools/flask/policy/modules/xen.te
> >>new file mode 100644
> >>index 0000000..f374dc5
> >>--- /dev/null
> >>+++ b/tools/flask/policy/modules/xen.te
> >.. snip..
> >
> >>+################################################################################
> >>+#
> >>+# 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 role is used for utility domains and pseudo-domains.  If roles are
> >>+# not being used for separation, all domains can use the system role.
> >>+role system_r;
> >>+role system_r types { xen_type dom0_t };
> >
> >Right here it is back again.
> >
> >Is the 'default_role' neccessary then?
> 
> Specifying some role is necessary to create a valid security label
> (which is a user:role:type tuple).
> 
> The line in xen.te only allows the pseudo-domains and dom0 to use
> system_r; this is a useful minimum, if you are going to place any
> actual guests in another role.  If you include default_role.te,
> then this expands to allowing all domains to use system_r.

Would it be better to rename 'default_role' to 'all_domains_access'
or such?

> 
> I could split the default_role extraction into a separate patch if
> you think this explanation belongs in a commit message.

It may be good for other newbies (like me) to get a gently introduction
via reading patches/code?
> 
> >I've looked at the original xen.te and them splitting out to individual and there were no
> >missing copy-n-paste (except the above 'default_role.te' which I am not
> >clear about).
> >
> >Thanks!
> >
> 
> 
> -- 
> Daniel De Graaf
> National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH 2/5] flask/policy: move user definitions and constraints into modules

[Daniel De Graaf]

This also renames the example users created by vm_role.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                            | 34 +++++++++++-----------
 tools/flask/policy/Makefile                        |  9 ++++--
 tools/flask/policy/modules/default_role.te         |  5 ----
 tools/flask/policy/modules/modules.conf            | 10 ++++++-
 .../{policy/constraints => modules/vm_role.cons}   |  6 ++--
 tools/flask/policy/modules/vm_role.te              | 16 ++++++++++
 tools/flask/policy/modules/xen.te                  |  9 ++++--
 tools/flask/policy/policy/support/misc_macros.spt  |  6 ++--
 tools/flask/policy/policy/users                    | 12 +-------
 9 files changed, 63 insertions(+), 44 deletions(-)
 rename tools/flask/policy/{policy/constraints => modules/vm_role.cons} (78%)
 create mode 100644 tools/flask/policy/modules/vm_role.te

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index d3015ca..2f42585 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -147,9 +147,11 @@ it relies on the SELinux compiler "checkpolicy"; run
 	make -C tools/flask/policy
 
 to compile the example policy included with Xen. The policy is generated from
-definition files under this directory. When creating or modifying security
-policy, most modifications will be made to the xen type enforcement (.te) file
-tools/flask/policy/policy/modules/xen/xen.te or the macro definitions in xen.if.
+definition files under this directory. Most changes to security policy will
+involve creating or modifying modules found in tools/flask/policy/modules/.  The
+modules.conf file there defines what modules are enabled and has short
+descriptions of each module.
+
 The XSM policy file needs to be copied to /boot and loaded as a module by grub.
 The exact position of the module does not matter as long as it is after the Xen
 kernel; it is normally placed either just above the dom0 kernel or at the end.
@@ -210,17 +212,16 @@ Type transitions are also used to compute the labels of event channels.
 Users and roles
 ---------------
 
-Users are defined in tools/flask/policy/policy/users. The example policy defines
-two users (customer_1 and customer_2) in addition to the system user system_u.
-Users are visible in the labels of domains and associated objects (event
-channels); in the example policy, "customer_1:vm_r:domU_t" is a valid label for
-the customer_1 user.
+The default user and role used for domains is system_u and system_r.  Users are
+visible in the labels of domains and associated objects (event channels); when
+the vm_role module is enabled, "user_1:vm_r:domU_t" is a valid label for a
+domain created by the user_1 user.
 
-Access control rules involving users and roles are defined in the policy
-constraints file (tools/flask/policy/policy/constraints). The example policy
-provides constraints that prevent different users from communicating using
-grants or event channels, while still allowing communication with the system_u
-user where dom0 resides.
+Access control rules involving users and roles are defined in a module's
+constraints file (for example, vm_rule.cons). The vm_role module defines one
+role (vm_r) and three users (user_1 .. user_3), along with constraints that
+prevent different users from communicating using grants or event channels, while
+still allowing communication with the system_u user where dom0 resides.
 
 Resource Policy
 ---------------
@@ -268,10 +269,9 @@ declare_domain and create_domain interfaces:
 Existing SELinux tools such as audit2allow can be applied to these denials, e.g.
 xl dmesg | audit2allow
 
-The generated allow rules can then be fed back into the policy by
-adding them to xen.te, although manual review is advised and will
-often lead to adding parameterized rules to the interfaces in xen.if
-to address the general case.
+The generated allow rules can then be fed back into the policy by adding them to
+a module, although manual review is advised and will often lead to adding
+parameterized rules to the interfaces in xen.if to address the general case.
 
 
 Device Labeling in Policy
diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index b2c2d06..693eb10 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -54,7 +54,6 @@ AVS += $(POLDIR)/access_vectors
 M4SUPPORT := $(wildcard $(POLDIR)/support/*.spt)
 MLSSUPPORT := $(POLDIR)/mls
 USERS := $(POLDIR)/users
-CONSTRAINTS := $(POLDIR)/constraints
 ISID_DEFS := $(POLDIR)/initial_sids
 DEV_OCONS := $(POLDIR)/device_contexts
 
@@ -90,8 +89,12 @@ MODENABLED := on
 # extract settings from modules.conf
 ENABLED_LIST := $(shell awk '/^[ \t]*[a-z]/{ if ($$3 == "$(MODENABLED)") print $$1 }' $(MOD_CONF) 2> /dev/null)
 
+# Modules must provide a .te file, although it could be empty
 ALL_MODULES := $(foreach mod,$(ENABLED_LIST),$(MODDIR)/$(mod).te)
+
+# Modules may also provide interfaces and constraint definitions
 ALL_INTERFACES := $(wildcard $(ALL_MODULES:.te=.if))
+ALL_CONSTRAINTS := $(wildcard $(ALL_MODULES:.te=.cons))
 
 # The order of these files is important
 POLICY_SECTIONS := $(SECCLASS) $(ISID_DECLS) $(AVS)
@@ -99,7 +102,9 @@ POLICY_SECTIONS += $(M4SUPPORT) $(MLSSUPPORT)
 POLICY_SECTIONS += $(ALL_INTERFACES)
 POLICY_SECTIONS += $(GLOBALTUN)
 POLICY_SECTIONS += $(ALL_MODULES)
-POLICY_SECTIONS += $(USERS) $(CONSTRAINTS) $(ISID_DEFS) $(DEV_OCONS)
+POLICY_SECTIONS += $(USERS)
+POLICY_SECTIONS += $(ALL_CONSTRAINTS)
+POLICY_SECTIONS += $(ISID_DEFS) $(DEV_OCONS)
 
 all: $(POLICY_FILENAME)
 
diff --git a/tools/flask/policy/modules/default_role.te b/tools/flask/policy/modules/default_role.te
index 74f870f..3018540 100644
--- a/tools/flask/policy/modules/default_role.te
+++ b/tools/flask/policy/modules/default_role.te
@@ -1,8 +1,3 @@
 # Allow all domains to use system_r so that systems that are not using the
 # user/role separation feature will work properly.
 role system_r types domain_type;
-
-# The vm role is used as part of user separation.  Allow all domain types to use
-# this role except dom0.
-role vm_r;
-role vm_r types { domain_type -dom0_t };
diff --git a/tools/flask/policy/modules/modules.conf b/tools/flask/policy/modules/modules.conf
index 5a1d905..2dfc011 100644
--- a/tools/flask/policy/modules/modules.conf
+++ b/tools/flask/policy/modules/modules.conf
@@ -33,5 +33,13 @@ nomigrate = on
 # Example device policy.  Also see policy/device_contexts.
 nic_dev = on
 
-# Example roles.  Also see policy/users.
+# Allow all domains to use system_u:system_r: instead of requiring explicit
+# roles.  This is not required for dom0_t, domU_t, and dm_dom_t.
 default_role = on
+
+# Example users, roles, and constraints for user-based separation.
+# 
+# The three users defined here can set up grant/event channel communication
+# (vchan, device frontend/backend) between their own VMs, but cannot set up a
+# channel to a VM under a different user.
+vm_role = on
diff --git a/tools/flask/policy/policy/constraints b/tools/flask/policy/modules/vm_role.cons
similarity index 78%
rename from tools/flask/policy/policy/constraints
rename to tools/flask/policy/modules/vm_role.cons
index 765ed4d..3847ec1 100644
--- a/tools/flask/policy/policy/constraints
+++ b/tools/flask/policy/modules/vm_role.cons
@@ -1,6 +1,5 @@
-
 #
-# Define the constraints
+# Constraints are defined by:
 #
 # constrain class_set perm_set expression ;
 #
@@ -25,8 +24,9 @@
 # name_list : name | name_list name
 #
 
-# Prevent event channels and grants between different customers
 
+# Prevent event channels and grants between different users.  This could be
+# further limited to only restricting those domains using the vm_r role.
 constrain event bind (
 	u1 == system_u or
 	u2 == system_u or
diff --git a/tools/flask/policy/modules/vm_role.te b/tools/flask/policy/modules/vm_role.te
new file mode 100644
index 0000000..f816de1
--- /dev/null
+++ b/tools/flask/policy/modules/vm_role.te
@@ -0,0 +1,16 @@
+# The vm role is used as part of user separation.  Allow all domain types to use
+# this role except dom0.
+role vm_r;
+role vm_r types { domain_type -dom0_t };
+
+# Define some users that must use this role (full type "user_1:vm_r:domU_t").
+gen_user(user_1,, vm_r, s0, s0)
+gen_user(user_2,, vm_r, s0, s0)
+gen_user(user_3,, vm_r, s0, s0)
+
+# Alternate: define and use a macro to generate 1000 users
+define(`def_vm_users',`gen_user(user_$1,, vm_r, s0, s0)
+ifelse(`$1',`$2',,`def_vm_users(incr($1),$2)')dnl
+')
+
+# def_vm_users(0,999)
diff --git a/tools/flask/policy/modules/xen.te b/tools/flask/policy/modules/xen.te
index f374dc5..b52edc2 100644
--- a/tools/flask/policy/modules/xen.te
+++ b/tools/flask/policy/modules/xen.te
@@ -71,14 +71,17 @@ neverallow * ~event_type:event { create send status };
 
 ################################################################################
 #
-# Roles
+# 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 role is used for utility domains and pseudo-domains.  If roles are
-# not being used for separation, all domains can use the system role.
+# 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 };
diff --git a/tools/flask/policy/policy/support/misc_macros.spt b/tools/flask/policy/policy/support/misc_macros.spt
index 2b27955..344f5c4 100644
--- a/tools/flask/policy/policy/support/misc_macros.spt
+++ b/tools/flask/policy/policy/support/misc_macros.spt
@@ -49,9 +49,11 @@ define(`refpolicyerr',`errprint(__file__:__line__: Error: `$1'__endline__)')
 #
 # gen_user(username, prefix, role_set, mls_defaultlevel, mls_range)
 #
-define(`gen_user',`dnl
+define(`gen_user',`define(`gen_all_users', gen_all_users `dnl
 user $1 roles { $3 }`'ifdef(`enable_mls', ` level $4 range $5')`';
-')
+')')
+
+define(`gen_all_users',`')
 
 ########################################
 #
diff --git a/tools/flask/policy/policy/users b/tools/flask/policy/policy/users
index 35ed8a9..af6acbd 100644
--- a/tools/flask/policy/policy/users
+++ b/tools/flask/policy/policy/users
@@ -1,11 +1 @@
-##################################
-#
-# System User configuration.
-#
-
-# system_u is the user identity for system domains and objects
-gen_user(system_u,, system_r, s0, s0 - mls_systemhigh)
-
-# Other users are defined using the vm role
-gen_user(customer_1,, vm_r, s0, s0)
-gen_user(customer_2,, vm_r, s0, s0)
+gen_all_users()
-- 
2.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 2/5] flask/policy: move user definitions and constraints into modules

[Konrad Rzeszutek Wilk]

On Mon, May 23, 2016 at 11:05:30AM -0400, Daniel De Graaf wrote:
> This also renames the example users created by vm_role.

Hey! Thank you for posting this.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  docs/misc/xsm-flask.txt                            | 34 +++++++++++-----------
>  tools/flask/policy/Makefile                        |  9 ++++--
>  tools/flask/policy/modules/default_role.te         |  5 ----
>  tools/flask/policy/modules/modules.conf            | 10 ++++++-
>  .../{policy/constraints => modules/vm_role.cons}   |  6 ++--
>  tools/flask/policy/modules/vm_role.te              | 16 ++++++++++
>  tools/flask/policy/modules/xen.te                  |  9 ++++--
>  tools/flask/policy/policy/support/misc_macros.spt  |  6 ++--
>  tools/flask/policy/policy/users                    | 12 +-------
>  9 files changed, 63 insertions(+), 44 deletions(-)
>  rename tools/flask/policy/{policy/constraints => modules/vm_role.cons} (78%)
>  create mode 100644 tools/flask/policy/modules/vm_role.te
> 
> diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
> index d3015ca..2f42585 100644
> --- a/docs/misc/xsm-flask.txt
> +++ b/docs/misc/xsm-flask.txt
> @@ -147,9 +147,11 @@ it relies on the SELinux compiler "checkpolicy"; run
>  	make -C tools/flask/policy
>  
>  to compile the example policy included with Xen. The policy is generated from
> -definition files under this directory. When creating or modifying security
> -policy, most modifications will be made to the xen type enforcement (.te) file
> -tools/flask/policy/policy/modules/xen/xen.te or the macro definitions in xen.if.
> +definition files under this directory. Most changes to security policy will
> +involve creating or modifying modules found in tools/flask/policy/modules/.  The
> +modules.conf file there defines what modules are enabled and has short
> +descriptions of each module.
> +
>  The XSM policy file needs to be copied to /boot and loaded as a module by grub.
>  The exact position of the module does not matter as long as it is after the Xen
>  kernel; it is normally placed either just above the dom0 kernel or at the end.
> @@ -210,17 +212,16 @@ Type transitions are also used to compute the labels of event channels.
>  Users and roles
>  ---------------
>  
> -Users are defined in tools/flask/policy/policy/users. The example policy defines
> -two users (customer_1 and customer_2) in addition to the system user system_u.
> -Users are visible in the labels of domains and associated objects (event
> -channels); in the example policy, "customer_1:vm_r:domU_t" is a valid label for
> -the customer_1 user.
> +The default user and role used for domains is system_u and system_r.  Users are
> +visible in the labels of domains and associated objects (event channels); when
> +the vm_role module is enabled, "user_1:vm_r:domU_t" is a valid label for a
> +domain created by the user_1 user.
>  
> -Access control rules involving users and roles are defined in the policy
> -constraints file (tools/flask/policy/policy/constraints). The example policy
> -provides constraints that prevent different users from communicating using
> -grants or event channels, while still allowing communication with the system_u
> -user where dom0 resides.
> +Access control rules involving users and roles are defined in a module's
> +constraints file (for example, vm_rule.cons). The vm_role module defines one
> +role (vm_r) and three users (user_1 .. user_3), along with constraints that
> +prevent different users from communicating using grants or event channels, while
> +still allowing communication with the system_u user where dom0 resides.
>  
>  Resource Policy
>  ---------------
> @@ -268,10 +269,9 @@ declare_domain and create_domain interfaces:
>  Existing SELinux tools such as audit2allow can be applied to these denials, e.g.
>  xl dmesg | audit2allow
>  
> -The generated allow rules can then be fed back into the policy by
> -adding them to xen.te, although manual review is advised and will
> -often lead to adding parameterized rules to the interfaces in xen.if
> -to address the general case.
> +The generated allow rules can then be fed back into the policy by adding them to
> +a module, although manual review is advised and will often lead to adding
> +parameterized rules to the interfaces in xen.if to address the general case.
>  
>  
>  Device Labeling in Policy
> diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
> index b2c2d06..693eb10 100644
> --- a/tools/flask/policy/Makefile
> +++ b/tools/flask/policy/Makefile
> @@ -54,7 +54,6 @@ AVS += $(POLDIR)/access_vectors
>  M4SUPPORT := $(wildcard $(POLDIR)/support/*.spt)
>  MLSSUPPORT := $(POLDIR)/mls
>  USERS := $(POLDIR)/users
> -CONSTRAINTS := $(POLDIR)/constraints
>  ISID_DEFS := $(POLDIR)/initial_sids
>  DEV_OCONS := $(POLDIR)/device_contexts
>  
> @@ -90,8 +89,12 @@ MODENABLED := on
>  # extract settings from modules.conf
>  ENABLED_LIST := $(shell awk '/^[ \t]*[a-z]/{ if ($$3 == "$(MODENABLED)") print $$1 }' $(MOD_CONF) 2> /dev/null)
>  
> +# Modules must provide a .te file, although it could be empty
>  ALL_MODULES := $(foreach mod,$(ENABLED_LIST),$(MODDIR)/$(mod).te)
> +
> +# Modules may also provide interfaces and constraint definitions
>  ALL_INTERFACES := $(wildcard $(ALL_MODULES:.te=.if))
> +ALL_CONSTRAINTS := $(wildcard $(ALL_MODULES:.te=.cons))
>  
>  # The order of these files is important
>  POLICY_SECTIONS := $(SECCLASS) $(ISID_DECLS) $(AVS)
> @@ -99,7 +102,9 @@ POLICY_SECTIONS += $(M4SUPPORT) $(MLSSUPPORT)
>  POLICY_SECTIONS += $(ALL_INTERFACES)
>  POLICY_SECTIONS += $(GLOBALTUN)
>  POLICY_SECTIONS += $(ALL_MODULES)
> -POLICY_SECTIONS += $(USERS) $(CONSTRAINTS) $(ISID_DEFS) $(DEV_OCONS)
> +POLICY_SECTIONS += $(USERS)
> +POLICY_SECTIONS += $(ALL_CONSTRAINTS)
> +POLICY_SECTIONS += $(ISID_DEFS) $(DEV_OCONS)
>  
>  all: $(POLICY_FILENAME)
>  
> diff --git a/tools/flask/policy/modules/default_role.te b/tools/flask/policy/modules/default_role.te
> index 74f870f..3018540 100644
> --- a/tools/flask/policy/modules/default_role.te
> +++ b/tools/flask/policy/modules/default_role.te
> @@ -1,8 +1,3 @@
>  # Allow all domains to use system_r so that systems that are not using the
>  # user/role separation feature will work properly.
>  role system_r types domain_type;
> -
> -# The vm role is used as part of user separation.  Allow all domain types to use
> -# this role except dom0.
> -role vm_r;
> -role vm_r types { domain_type -dom0_t };
> diff --git a/tools/flask/policy/modules/modules.conf b/tools/flask/policy/modules/modules.conf
> index 5a1d905..2dfc011 100644
> --- a/tools/flask/policy/modules/modules.conf
> +++ b/tools/flask/policy/modules/modules.conf
> @@ -33,5 +33,13 @@ nomigrate = on
>  # Example device policy.  Also see policy/device_contexts.
>  nic_dev = on
>  
> -# Example roles.  Also see policy/users.
> +# Allow all domains to use system_u:system_r: instead of requiring explicit
> +# roles.  This is not required for dom0_t, domU_t, and dm_dom_t.
>  default_role = on
> +
> +# Example users, roles, and constraints for user-based separation.
> +# 
> +# The three users defined here can set up grant/event channel communication
> +# (vchan, device frontend/backend) between their own VMs, but cannot set up a
> +# channel to a VM under a different user.
> +vm_role = on
> diff --git a/tools/flask/policy/policy/constraints b/tools/flask/policy/modules/vm_role.cons
> similarity index 78%
> rename from tools/flask/policy/policy/constraints
> rename to tools/flask/policy/modules/vm_role.cons
> index 765ed4d..3847ec1 100644
> --- a/tools/flask/policy/policy/constraints
> +++ b/tools/flask/policy/modules/vm_role.cons
> @@ -1,6 +1,5 @@
> -
>  #
> -# Define the constraints
> +# Constraints are defined by:
>  #
>  # constrain class_set perm_set expression ;
>  #
> @@ -25,8 +24,9 @@
>  # name_list : name | name_list name
>  #
>  
> -# Prevent event channels and grants between different customers
>  
> +# Prevent event channels and grants between different users.  This could be
> +# further limited to only restricting those domains using the vm_r role.
>  constrain event bind (
>  	u1 == system_u or
>  	u2 == system_u or

So right up to here I followed it. But for later part  I am afraid I need to 
study the policy language to grok it.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH 3/5] flask/policy: Remove unused support for binary modules

[Daniel De Graaf]

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 .../policy/policy/support/loadable_module.spt      | 166 ---------------------
 tools/flask/policy/policy/support/misc_macros.spt  |   2 +
 2 files changed, 2 insertions(+), 166 deletions(-)
 delete mode 100644 tools/flask/policy/policy/support/loadable_module.spt

diff --git a/tools/flask/policy/policy/support/loadable_module.spt b/tools/flask/policy/policy/support/loadable_module.spt
deleted file mode 100644
index de48b3b..0000000
--- a/tools/flask/policy/policy/support/loadable_module.spt
+++ /dev/null
@@ -1,166 +0,0 @@
-########################################
-#
-# Macros for switching between source policy
-# and loadable policy module support
-#
-
-##############################
-#
-# For adding the module statement
-#
-define(`policy_module',`
-	ifdef(`self_contained_policy',`',`
-		module $1 $2;
-
-		require {
-			role system_r;
-			all_kernel_class_perms
-		}
-	')
-')
-
-##############################
-#
-# For use in interfaces, to optionally insert a require block
-#
-define(`gen_require',`
-	ifdef(`self_contained_policy',`',`
-		define(`in_gen_require_block')
-		require {
-			$1
-		}
-		undefine(`in_gen_require_block')
-	')
-')
-
-##############################
-#
-# In the future interfaces should be in loadable modules
-#
-# template(name,rules)
-#
-define(`template',`
-	`define(`$1',`
-##### begin $1(dollarsstar)
-		$2
-##### end $1(dollarsstar)
-	'')
-')
-
-# helper function, since m4 wont expand macros
-# if a line is a comment (#):
-define(`policy_m4_comment',`dnl
-##### $2 depth: $1
-')dnl
-
-##############################
-#
-# In the future interfaces should be in loadable modules
-#
-# interface(name,rules)
-#
-define(`interface',`
-	`define(`$1',`
-
-	define(`policy_temp',incr(policy_call_depth))
-	pushdef(`policy_call_depth',policy_temp)
-	undefine(`policy_temp')
-
-	policy_m4_comment(policy_call_depth,begin `$1'(dollarsstar))
-
-	$2
-
-	define(`policy_temp',decr(policy_call_depth))
-	pushdef(`policy_call_depth',policy_temp)
-	undefine(`policy_temp')
-
-	policy_m4_comment(policy_call_depth,end `$1'(dollarsstar))
-
-	'')
-')
-
-define(`policy_call_depth',0)
-
-##############################
-#
-# Optional policy handling
-#
-define(`optional_policy',`
-	ifdef(`self_contained_policy',`
-		ifdef(`$1',`$2',`$3')
-	',`
-		optional {
-			$2
-		ifelse(`$3',`',`',`
-		} else {
-			$3
-		')
-		}
-	')
-')
-
-##############################
-#
-# Determine if we should use the default
-# tunable value as specified by the policy
-# or if the override value should be used
-#
-define(`dflt_or_overr',`ifdef(`$1',$1,$2)')
-
-##############################
-#
-# Extract booleans out of an expression.
-# This needs to be reworked so expressions
-# with parentheses can work.
-
-define(`delcare_required_symbols',`
-ifelse(regexp($1, `\w'), -1, `', `dnl
-bool regexp($1, `\(\w+\)', `\1');
-delcare_required_symbols(regexp($1, `\w+\(.*\)', `\1'))dnl
-') dnl
-')
-
-##############################
-#
-# Tunable declaration
-#
-define(`gen_tunable',`
-	ifdef(`self_contained_policy',`
-		bool $1 dflt_or_overr(`$1'_conf,$2);
-	',`
-		# loadable module tunable
-		# declaration will go here
-		# instead of bool when
-		# loadable modules support
-		# tunables
-		bool $1 dflt_or_overr(`$1'_conf,$2);
-	')
-')
-
-##############################
-#
-# Tunable policy handling
-#
-define(`tunable_policy',`
-	ifdef(`self_contained_policy',`
-		if (`$1') {
-			$2
-		} else {
-			$3
-		}
-	',`
-		# structure for tunables
-		# will go here instead of a
-		# conditional when loadable
-		# modules support tunables
-		gen_require(`
-			delcare_required_symbols(`$1')
-		')
-
-		if (`$1') {
-			$2
-		} else {
-			$3
-		}
-	')
-')
diff --git a/tools/flask/policy/policy/support/misc_macros.spt b/tools/flask/policy/policy/support/misc_macros.spt
index 344f5c4..3116db9 100644
--- a/tools/flask/policy/policy/support/misc_macros.spt
+++ b/tools/flask/policy/policy/support/misc_macros.spt
@@ -61,6 +61,8 @@ define(`gen_all_users',`')
 #
 define(`gen_context',`$1`'ifdef(`enable_mls',`:$2')`'')
 
+define(`dflt_or_overr',`ifdef(`$1',$1,$2)')
+
 ########################################
 #
 # gen_bool(name,default_value)
-- 
2.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 3/5] flask/policy: Remove unused support for binary modules

[Konrad Rzeszutek Wilk]

On Mon, May 23, 2016 at 11:05:31AM -0400, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

with my very limited knowledge of the policy language.

But it just looks to delete a lot and copy-n-paste the dflt_or_overr
over. And none of these functions are used (except in the file that
is being deleted).


> ---
>  .../policy/policy/support/loadable_module.spt      | 166 ---------------------
>  tools/flask/policy/policy/support/misc_macros.spt  |   2 +
>  2 files changed, 2 insertions(+), 166 deletions(-)
>  delete mode 100644 tools/flask/policy/policy/support/loadable_module.spt
> 
> diff --git a/tools/flask/policy/policy/support/loadable_module.spt b/tools/flask/policy/policy/support/loadable_module.spt
> deleted file mode 100644
> index de48b3b..0000000
> --- a/tools/flask/policy/policy/support/loadable_module.spt
> +++ /dev/null
> @@ -1,166 +0,0 @@
> -########################################
> -#
> -# Macros for switching between source policy
> -# and loadable policy module support
> -#
> -
> -##############################
> -#
> -# For adding the module statement
> -#
> -define(`policy_module',`
> -	ifdef(`self_contained_policy',`',`
> -		module $1 $2;
> -
> -		require {
> -			role system_r;
> -			all_kernel_class_perms
> -		}
> -	')
> -')
> -
> -##############################
> -#
> -# For use in interfaces, to optionally insert a require block
> -#
> -define(`gen_require',`
> -	ifdef(`self_contained_policy',`',`
> -		define(`in_gen_require_block')
> -		require {
> -			$1
> -		}
> -		undefine(`in_gen_require_block')
> -	')
> -')
> -
> -##############################
> -#
> -# In the future interfaces should be in loadable modules
> -#
> -# template(name,rules)
> -#
> -define(`template',`
> -	`define(`$1',`
> -##### begin $1(dollarsstar)
> -		$2
> -##### end $1(dollarsstar)
> -	'')
> -')
> -
> -# helper function, since m4 wont expand macros
> -# if a line is a comment (#):
> -define(`policy_m4_comment',`dnl
> -##### $2 depth: $1
> -')dnl
> -
> -##############################
> -#
> -# In the future interfaces should be in loadable modules
> -#
> -# interface(name,rules)
> -#
> -define(`interface',`
> -	`define(`$1',`
> -
> -	define(`policy_temp',incr(policy_call_depth))
> -	pushdef(`policy_call_depth',policy_temp)
> -	undefine(`policy_temp')
> -
> -	policy_m4_comment(policy_call_depth,begin `$1'(dollarsstar))
> -
> -	$2
> -
> -	define(`policy_temp',decr(policy_call_depth))
> -	pushdef(`policy_call_depth',policy_temp)
> -	undefine(`policy_temp')
> -
> -	policy_m4_comment(policy_call_depth,end `$1'(dollarsstar))
> -
> -	'')
> -')
> -
> -define(`policy_call_depth',0)
> -
> -##############################
> -#
> -# Optional policy handling
> -#
> -define(`optional_policy',`
> -	ifdef(`self_contained_policy',`
> -		ifdef(`$1',`$2',`$3')
> -	',`
> -		optional {
> -			$2
> -		ifelse(`$3',`',`',`
> -		} else {
> -			$3
> -		')
> -		}
> -	')
> -')
> -
> -##############################
> -#
> -# Determine if we should use the default
> -# tunable value as specified by the policy
> -# or if the override value should be used
> -#
> -define(`dflt_or_overr',`ifdef(`$1',$1,$2)')
> -
> -##############################
> -#
> -# Extract booleans out of an expression.
> -# This needs to be reworked so expressions
> -# with parentheses can work.
> -
> -define(`delcare_required_symbols',`
> -ifelse(regexp($1, `\w'), -1, `', `dnl
> -bool regexp($1, `\(\w+\)', `\1');
> -delcare_required_symbols(regexp($1, `\w+\(.*\)', `\1'))dnl
> -') dnl
> -')
> -
> -##############################
> -#
> -# Tunable declaration
> -#
> -define(`gen_tunable',`
> -	ifdef(`self_contained_policy',`
> -		bool $1 dflt_or_overr(`$1'_conf,$2);
> -	',`
> -		# loadable module tunable
> -		# declaration will go here
> -		# instead of bool when
> -		# loadable modules support
> -		# tunables
> -		bool $1 dflt_or_overr(`$1'_conf,$2);
> -	')
> -')
> -
> -##############################
> -#
> -# Tunable policy handling
> -#
> -define(`tunable_policy',`
> -	ifdef(`self_contained_policy',`
> -		if (`$1') {
> -			$2
> -		} else {
> -			$3
> -		}
> -	',`
> -		# structure for tunables
> -		# will go here instead of a
> -		# conditional when loadable
> -		# modules support tunables
> -		gen_require(`
> -			delcare_required_symbols(`$1')
> -		')
> -
> -		if (`$1') {
> -			$2
> -		} else {
> -			$3
> -		}
> -	')
> -')
> diff --git a/tools/flask/policy/policy/support/misc_macros.spt b/tools/flask/policy/policy/support/misc_macros.spt
> index 344f5c4..3116db9 100644
> --- a/tools/flask/policy/policy/support/misc_macros.spt
> +++ b/tools/flask/policy/policy/support/misc_macros.spt
> @@ -61,6 +61,8 @@ define(`gen_all_users',`')
>  #
>  define(`gen_context',`$1`'ifdef(`enable_mls',`:$2')`'')
>  
> +define(`dflt_or_overr',`ifdef(`$1',$1,$2)')
> +
>  ########################################
>  #
>  # gen_bool(name,default_value)
> -- 
> 2.5.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH 4/5] flask/policy: xenstore stubdom policy

[Daniel De Graaf]

This adds the xenstore_t type to the example policy for use by a
xenstore stub domain.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/modules/modules.conf |  3 +++
 tools/flask/policy/modules/xenstore.te  | 21 +++++++++++++++++++++
 2 files changed, 24 insertions(+)
 create mode 100644 tools/flask/policy/modules/xenstore.te

diff --git a/tools/flask/policy/modules/modules.conf b/tools/flask/policy/modules/modules.conf
index 2dfc011..8ffd00e 100644
--- a/tools/flask/policy/modules/modules.conf
+++ b/tools/flask/policy/modules/modules.conf
@@ -33,6 +33,9 @@ nomigrate = on
 # Example device policy.  Also see policy/device_contexts.
 nic_dev = on
 
+# Xenstore stub domain.
+xenstore = on
+
 # Allow all domains to use system_u:system_r: instead of requiring explicit
 # roles.  This is not required for dom0_t, domU_t, and dm_dom_t.
 default_role = on
diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te
new file mode 100644
index 0000000..2ae7a1d
--- /dev/null
+++ b/tools/flask/policy/modules/xenstore.te
@@ -0,0 +1,21 @@
+################################################################################
+#
+# Xenstore stubdomain
+#
+################################################################################
+declare_singleton_domain(xenstore_t)
+create_domain(dom0_t, xenstore_t)
+manage_domain(dom0_t, xenstore_t)
+
+# Xenstore requires the global VIRQ for domain destroy operations
+allow dom0_t xenstore_t:domain set_virq_handler;
+# Current xenstore stubdom uses the hypervisor console, not "xl console"
+allow xenstore_t xen_t:xen writeconsole;
+# Xenstore queries domaininfo on all domains
+allow xenstore_t domain_type:domain getdomaininfo;
+
+# As a shortcut, the following 3 rules are used instead of adding a domain_comms
+# rule between xenstore_t and every domain type that talks to xenstore
+create_channel(xenstore_t, domain_type, xenstore_t_channel)
+allow event_type xenstore_t: event bind;
+allow xenstore_t domain_type:grant { map_read map_write unmap };
-- 
2.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 4/5] flask/policy: xenstore stubdom policy

[Konrad Rzeszutek Wilk]

On Mon, May 23, 2016 at 11:05:32AM -0400, Daniel De Graaf wrote:
> This adds the xenstore_t type to the example policy for use by a
> xenstore stub domain.

Is there a link somewhere or docs that oultines how to how
create/build such stub domain? The docs/misc/stubdom.txt sadly does not
have any data?

> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/flask/policy/modules/modules.conf |  3 +++
>  tools/flask/policy/modules/xenstore.te  | 21 +++++++++++++++++++++
>  2 files changed, 24 insertions(+)
>  create mode 100644 tools/flask/policy/modules/xenstore.te
> 
> diff --git a/tools/flask/policy/modules/modules.conf b/tools/flask/policy/modules/modules.conf
> index 2dfc011..8ffd00e 100644
> --- a/tools/flask/policy/modules/modules.conf
> +++ b/tools/flask/policy/modules/modules.conf
> @@ -33,6 +33,9 @@ nomigrate = on
>  # Example device policy.  Also see policy/device_contexts.
>  nic_dev = on
>  
> +# Xenstore stub domain.
> +xenstore = on
> +
>  # Allow all domains to use system_u:system_r: instead of requiring explicit
>  # roles.  This is not required for dom0_t, domU_t, and dm_dom_t.
>  default_role = on
> diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te
> new file mode 100644
> index 0000000..2ae7a1d
> --- /dev/null
> +++ b/tools/flask/policy/modules/xenstore.te
> @@ -0,0 +1,21 @@
> +################################################################################
> +#
> +# Xenstore stubdomain
> +#
> +################################################################################
> +declare_singleton_domain(xenstore_t)
> +create_domain(dom0_t, xenstore_t)
> +manage_domain(dom0_t, xenstore_t)
> +
> +# Xenstore requires the global VIRQ for domain destroy operations
> +allow dom0_t xenstore_t:domain set_virq_handler;
> +# Current xenstore stubdom uses the hypervisor console, not "xl console"
> +allow xenstore_t xen_t:xen writeconsole;
> +# Xenstore queries domaininfo on all domains
> +allow xenstore_t domain_type:domain getdomaininfo;
> +
> +# As a shortcut, the following 3 rules are used instead of adding a domain_comms
> +# rule between xenstore_t and every domain type that talks to xenstore
> +create_channel(xenstore_t, domain_type, xenstore_t_channel)
> +allow event_type xenstore_t: event bind;
> +allow xenstore_t domain_type:grant { map_read map_write unmap };
> -- 
> 2.5.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 4/5] flask/policy: xenstore stubdom policy

[Daniel De Graaf]

On 06/07/2016 03:44 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, May 23, 2016 at 11:05:32AM -0400, Daniel De Graaf wrote:
>> This adds the xenstore_t type to the example policy for use by a
>> xenstore stub domain.
>
> Is there a link somewhere or docs that oultines how to how
> create/build such stub domain? The docs/misc/stubdom.txt sadly does not
> have any data?

I believe it is built by "make stubdom" unless you passed the
--disable-xenstore-stubdom to configure.  Starting the stubdom
has to be done using init-xenstore-domain from tools/helpers.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 4/5] flask/policy: xenstore stubdom policy

[Konrad Rzeszutek Wilk]

On Tue, Jun 07, 2016 at 03:48:02PM -0400, Daniel De Graaf wrote:
> On 06/07/2016 03:44 PM, Konrad Rzeszutek Wilk wrote:
> >On Mon, May 23, 2016 at 11:05:32AM -0400, Daniel De Graaf wrote:
> >>This adds the xenstore_t type to the example policy for use by a
> >>xenstore stub domain.
> >
> >Is there a link somewhere or docs that oultines how to how
> >create/build such stub domain? The docs/misc/stubdom.txt sadly does not
> >have any data?
> 
> I believe it is built by "make stubdom" unless you passed the
> --disable-xenstore-stubdom to configure.  Starting the stubdom
> has to be done using init-xenstore-domain from tools/helpers.

Thanks!

Let me try that out!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

default XSM policy for PCI passthrough for unlabeled resources.

[anshul makkar]

Hi,

Default XSM policy doesn't allow the use of unlabeled PCI resources that 
have been passed through to target domain.

xen.te
# Resources must be declared using . resource_type 

neverallow * ~resource_type:resource use;

It allows the resource to be added and removed by the source domain to 
target domain, but its use by target domain is blocked.

The resource can be used only if it has been labeled using 
flask-label-pci command which needs to be rerun after every boot and 
after every policy reload.

The above approach reduces the flexibility and necessitates admin 
intervention to give passthrough rights after host has booted. Also, in 
general if I want to allow all domUs to have PCI passthough access to 
all PCI device, I have no other way apart from disabling the 
"neverallow" rule.

Given that what we ship is just a sample default policy for reference 
which is expected to be permissive in most of the scenarios so that it 
doesn't affect the basic functionalities, is this "neverallow" rule needed ?

Thanks
Anshul Makkar









_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: default XSM policy for PCI passthrough for unlabeled resources.

[Daniel De Graaf]

On 07/06/2016 11:34 AM, anshul makkar wrote:
> Hi,
>
> Default XSM policy doesn't allow the use of unlabeled PCI resources that have been passed through to target domain.
>
> xen.te
> # Resources must be declared using . resource_type
> neverallow * ~resource_type:resource use;
>
> It allows the resource to be added and removed by the source domain to target domain, but its use by target domain is blocked.

This rule only mandates the use of resource_type for resource types.  If you are creating a new resource type, follow the example in nic_dev.te.

> The resource can be used only if it has been labeled using flask-label-pci command which needs to be rerun after every boot and after every policy reload.

Yes; this gives the most control over what resources can be delegated.  Policy reloads are supposed to be rare (on a production system) and you already need special boot scripts (or parameters) to set up the device for passthrough, so this can be added there.  However, I agree this can be more work than a "default" FLASK policy should require.

> The above approach reduces the flexibility and necessitates admin intervention to give passthrough rights after host has booted. Also, in general if I want to allow all domUs to have PCI passthough access to all PCI device, I have no other way apart from disabling the "neverallow" rule.

Try adding a module with the following rules, which should allow domU to use unlabeled devices:

use_device(domU_t, irq_t)
use_device(domU_t, ioport_t)
use_device(domU_t, iomem_t)
use_device(domU_t, device_t)

If this works, that module could be added to the default policy.

> Given that what we ship is just a sample default policy for reference which is expected to be permissive in most of the scenarios so that it doesn't affect the basic functionalities, is this "neverallow" rule needed ?
>
> Thanks
> Anshul Makkar

The neverallow rules are just there to ensure that the attributes are being used correctly.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: default XSM policy for PCI passthrough for unlabeled resources.

[anshul makkar]

On 06/07/16 16:59, Daniel De Graaf wrote:
> On 07/06/2016 11:34 AM, anshul makkar wrote:
>> Hi,
>>
>>
>> It allows the resource to be added and removed by the source domain to
>> target domain, but its use by target domain is blocked.
>
> This rule only mandates the use of resource_type for resource types.  If
> you are creating a new resource type, follow the example in nic_dev.te.
Agreed, but inherently it means that "use" of any unlabeled resource be 
it irq, ioport or iomem or nic_dev is restricted.
>
>> The resource can be used only if it has been labeled using
>> flask-label-pci command which needs to be rerun after every boot and
>> after every policy reload.
>
> Yes; this gives the most control over what resources can be delegated.
> Policy reloads are supposed to be rare (on a production system) and you
> already need special boot scripts (or parameters) to set up the device
> for passthrough, so this can be added there.  However, I agree this can
> be more work than a "default" FLASK policy should require.
>
> Try adding a module with the following rules, which should allow domU to
> use unlabeled devices:
>
> use_device(domU_t, irq_t)
> use_device(domU_t, ioport_t)
> use_device(domU_t, iomem_t)
> use_device(domU_t, device_t)
Yes, it does work , but I have added these in delegate_device to make it 
restrict to the case where there is delegation.
>
> If this works, that module could be added to the default policy.
>
>> Given that what we ship is just a sample default policy for reference
>> which is expected to be permissive in most of the scenarios so that it
>> doesn't affect the basic functionalities, is this "neverallow" rule
>> needed ?
>>
>> Thanks
>> Anshul Makkar
>
> The neverallow rules are just there to ensure that the attributes are
> being used correctly.
>
Anshul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: default XSM policy for PCI passthrough for unlabeled resources.

[Daniel De Graaf]

On 07/06/2016 12:19 PM, anshul makkar wrote:
> On 06/07/16 16:59, Daniel De Graaf wrote:
>> On 07/06/2016 11:34 AM, anshul makkar wrote:
>>> Hi,
>>>
>>>
>>> It allows the resource to be added and removed by the source domain to
>>> target domain, but its use by target domain is blocked.
>>
>> This rule only mandates the use of resource_type for resource types.  If
>> you are creating a new resource type, follow the example in nic_dev.te.
> Agreed, but inherently it means that "use" of any unlabeled resource be it irq, ioport or iomem or nic_dev is restricted.

Restricted how?  The fallback types have the resource_type attribute.

Neverallow rules are actually not present in the binary policy; they act as
compile-time assertions in the policy build.

>>
>>> The resource can be used only if it has been labeled using
>>> flask-label-pci command which needs to be rerun after every boot and
>>> after every policy reload.
>>
>> Yes; this gives the most control over what resources can be delegated.
>> Policy reloads are supposed to be rare (on a production system) and you
>> already need special boot scripts (or parameters) to set up the device
>> for passthrough, so this can be added there.  However, I agree this can
>> be more work than a "default" FLASK policy should require.
>>
>> Try adding a module with the following rules, which should allow domU to
>> use unlabeled devices:
>>
>> use_device(domU_t, irq_t)
>> use_device(domU_t, ioport_t)
>> use_device(domU_t, iomem_t)
>> use_device(domU_t, device_t)
> Yes, it does work , but I have added these in delegate_device to make it restrict to the case where there is delegation.

This prevents using delegate_devices without allowing access to unlabeled
devices.  If you think this should be a macro, I would suggest making a new
one named something like "delegate_unlabeled_devices".

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: default XSM policy for PCI passthrough for unlabeled resources.

[anshul makkar]

On 07/07/16 16:36, Daniel De Graaf wrote:
> On 07/06/2016 12:19 PM, anshul makkar wrote:
>> On 06/07/16 16:59, Daniel De Graaf wrote:
>>> On 07/06/2016 11:34 AM, anshul makkar wrote:
>>>> Hi,
>>>>
>>>>
>>>> It allows the resource to be added and removed by the source domain to
>>>> target domain, but its use by target domain is blocked.
>>>
>>> This rule only mandates the use of resource_type for resource types.  If
>>> you are creating a new resource type, follow the example in nic_dev.te.
>> Agreed, but inherently it means that "use" of any unlabeled resource
>> be it irq, ioport or iomem or nic_dev is restricted.
>
> Restricted how?  The fallback types have the resource_type attribute.
Restricted if they are unlabeled.
>
> Neverallow rules are actually not present in the binary policy; they act as
> compile-time assertions in the policy build.
>
Fine.
>>>
>>>> The resource can be used only if it has been labeled using
>>>> flask-label-pci command which needs to be rerun after every boot and
>>>> after every policy reload.
>>>
>>>
>>> Try adding a module with the following rules, which should allow domU to
>>> use unlabeled devices:
>>>
>>> use_device(domU_t, irq_t)
>>> use_device(domU_t, ioport_t)
>>> use_device(domU_t, iomem_t)
>>> use_device(domU_t, device_t)
>> Yes, it does work , but I have added these in delegate_device to make
>> it restrict to the case where there is delegation.
>
> This prevents using delegate_devices without allowing access to unlabeled
> devices.  If you think this should be a macro, I would suggest making a new
> one named something like "delegate_unlabeled_devices".
>

Agreed. That's a better approach.
I believe this macro can make the default policy more flexible and 
useful for more general audience, so it should be there in the policy. I 
can submit patch for the same. Your thoughts ?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH 5/5] flask/policy: comment out unused xenstore example

[Daniel De Graaf]

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/access_vectors   | 32 +++++++++++++++---------------
 tools/flask/policy/policy/security_classes |  2 +-
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/tools/flask/policy/policy/access_vectors b/tools/flask/policy/policy/access_vectors
index 4fd61f1..8cca192 100644
--- a/tools/flask/policy/policy/access_vectors
+++ b/tools/flask/policy/policy/access_vectors
@@ -6,19 +6,19 @@
 # Note: this is an example; the xenstore daemon provided with Xen does
 # not yet include XSM support, and the exact permissions may be defined
 # differently if such support is added.
-class xenstore {
-	# read from keys owned by the target domain (if permissions allow)
-	read
-	# write to keys owned by the target domain (if permissions allow)
-	write
-	# change permissions of a key owned by the target domain
-	chmod
-	# change the owner of a key which was owned by the target domain
-	chown_from
-	# change the owner of a key to the target domain
-	chown_to
-	# access a key owned by the target domain without permission
-	override
-	# introduce a domain
-	introduce
-}
+#class xenstore {
+#	# read from keys owned by the target domain (if permissions allow)
+#	read
+#	# write to keys owned by the target domain (if permissions allow)
+#	write
+#	# change permissions of a key owned by the target domain
+#	chmod
+#	# change the owner of a key which was owned by the target domain
+#	chown_from
+#	# change the owner of a key to the target domain
+#	chown_to
+#	# access a key owned by the target domain without permission
+#	override
+#	# introduce a domain
+#	introduce
+#}
diff --git a/tools/flask/policy/policy/security_classes b/tools/flask/policy/policy/security_classes
index 56595e8..069faea 100644
--- a/tools/flask/policy/policy/security_classes
+++ b/tools/flask/policy/policy/security_classes
@@ -5,4 +5,4 @@
 # security policy.
 #
 # Access vectors for these classes must be defined in the access_vectors file.
-class xenstore
+#class xenstore
-- 
2.5.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 5/5] flask/policy: comment out unused xenstore example

[Konrad Rzeszutek Wilk]

On Mon, May 23, 2016 at 11:05:33AM -0400, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Would it be good to include in the description something like:

"You should be using the xenstore stubdomain".?

Thanks.
> ---
>  tools/flask/policy/policy/access_vectors   | 32 +++++++++++++++---------------
>  tools/flask/policy/policy/security_classes |  2 +-
>  2 files changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/tools/flask/policy/policy/access_vectors b/tools/flask/policy/policy/access_vectors
> index 4fd61f1..8cca192 100644
> --- a/tools/flask/policy/policy/access_vectors
> +++ b/tools/flask/policy/policy/access_vectors
> @@ -6,19 +6,19 @@
>  # Note: this is an example; the xenstore daemon provided with Xen does
>  # not yet include XSM support, and the exact permissions may be defined
>  # differently if such support is added.
> -class xenstore {
> -	# read from keys owned by the target domain (if permissions allow)
> -	read
> -	# write to keys owned by the target domain (if permissions allow)
> -	write
> -	# change permissions of a key owned by the target domain
> -	chmod
> -	# change the owner of a key which was owned by the target domain
> -	chown_from
> -	# change the owner of a key to the target domain
> -	chown_to
> -	# access a key owned by the target domain without permission
> -	override
> -	# introduce a domain
> -	introduce
> -}
> +#class xenstore {
> +#	# read from keys owned by the target domain (if permissions allow)
> +#	read
> +#	# write to keys owned by the target domain (if permissions allow)
> +#	write
> +#	# change permissions of a key owned by the target domain
> +#	chmod
> +#	# change the owner of a key which was owned by the target domain
> +#	chown_from
> +#	# change the owner of a key to the target domain
> +#	chown_to
> +#	# access a key owned by the target domain without permission
> +#	override
> +#	# introduce a domain
> +#	introduce
> +#}
> diff --git a/tools/flask/policy/policy/security_classes b/tools/flask/policy/policy/security_classes
> index 56595e8..069faea 100644
> --- a/tools/flask/policy/policy/security_classes
> +++ b/tools/flask/policy/policy/security_classes
> @@ -5,4 +5,4 @@
>  # security policy.
>  #
>  # Access vectors for these classes must be defined in the access_vectors file.
> -class xenstore
> +#class xenstore
> -- 
> 2.5.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 5/5] flask/policy: comment out unused xenstore example

[Daniel De Graaf]

On 06/07/2016 03:45 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, May 23, 2016 at 11:05:33AM -0400, Daniel De Graaf wrote:
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>
> Would it be good to include in the description something like:
>
> "You should be using the xenstore stubdomain".?
>
> Thanks.

This is unrelated to the xenstore stubdomain; these permissions were
never actually used.  They were pulled from an earlier design document
for a xenstore daemon that added security permissions to xenstore keys
and operations, but this was never a part of upstream Xen.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 5/5] flask/policy: comment out unused xenstore example

[Konrad Rzeszutek Wilk]

On Tue, Jun 07, 2016 at 03:51:20PM -0400, Daniel De Graaf wrote:
> On 06/07/2016 03:45 PM, Konrad Rzeszutek Wilk wrote:
> >On Mon, May 23, 2016 at 11:05:33AM -0400, Daniel De Graaf wrote:
> >>Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >
> >Would it be good to include in the description something like:
> >
> >"You should be using the xenstore stubdomain".?
> >
> >Thanks.
> 
> This is unrelated to the xenstore stubdomain; these permissions were
> never actually used.  They were pulled from an earlier design document
> for a xenstore daemon that added security permissions to xenstore keys
> and operations, but this was never a part of upstream Xen.
> 

Would it be just easier to delete it?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH 5/5] flask/policy: comment out unused xenstore example

[Daniel De Graaf]

On 06/07/2016 04:02 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 07, 2016 at 03:51:20PM -0400, Daniel De Graaf wrote:
>> On 06/07/2016 03:45 PM, Konrad Rzeszutek Wilk wrote:
>>> On Mon, May 23, 2016 at 11:05:33AM -0400, Daniel De Graaf wrote:
>>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>
>>> Would it be good to include in the description something like:
>>>
>>> "You should be using the xenstore stubdomain".?
>>>
>>> Thanks.
>>
>> This is unrelated to the xenstore stubdomain; these permissions were
>> never actually used.  They were pulled from an earlier design document
>> for a xenstore daemon that added security permissions to xenstore keys
>> and operations, but this was never a part of upstream Xen.
>>
>
> Would it be just easier to delete it?
>

That works too.  It was left as an example so that it could be added
back in the future easily, but git history is easy enough to find.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel