[PATCH 00/15] XSM/FLASK updates for 4.8

[PATCH 00/15] XSM/FLASK updates for 4.8

[Daniel De Graaf]

Some of these patches have been posted before (patch 11 was posted in
2014; an earlier variant of 1-6 and 15 were posted recently as RFC).
The rest are mostly removal of unused code or other cleanup.

FLASK policy updates:
[PATCH 01/15] flask/policy: split into modules
[PATCH 02/15] flask/policy: split out rules for system_r
[PATCH 03/15] flask/policy: move user definitions and constraints
[PATCH 04/15] flask/policy: remove unused support for binary modules
[PATCH 05/15] flask/policy: xenstore stubdom policy
[PATCH 06/15] flask/policy: remove unused example

Hypervisor updates to the FLASK security server:
[PATCH 07/15] flask: unify {get,set}vcpucontext permissions
[PATCH 08/15] flask: remove unused secondary context in ocontext
[PATCH 09/15] flask: remove unused AVC callback functions
[PATCH 10/15] flask: remove xen_flask_userlist operation
[PATCH 11/15] flask: improve unknown permission handling

Hypervisor updates to the XSM framework:
[PATCH 12/15] xen/xsm: remove .xsm_initcall.init section
[PATCH 13/15] xsm: annotate setup functions with __init
[PATCH 14/15] xsm: clean up unregistration
[PATCH 15/15] xsm: add a default policy to .init.data

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

[PATCH 01/15] 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/dom0.te                 |  74 ++++++
 tools/flask/policy/modules/domU.te                 |  25 ++
 tools/flask/policy/modules/guest_features.te       |  31 +++
 tools/flask/policy/modules/isolated_domU.te        |   7 +
 tools/flask/policy/modules/modules.conf            |  34 +++
 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                  |  89 +++++++
 tools/flask/policy/policy/modules.conf             |  15 --
 tools/flask/policy/policy/modules/xen/xen.te       | 272 ---------------------
 13 files changed, 302 insertions(+), 302 deletions(-)
 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/dom0.te b/tools/flask/policy/modules/dom0.te
new file mode 100644
index 0000000..ef6a986
--- /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 livepatch_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..ca5eecd
--- /dev/null
+++ b/tools/flask/policy/modules/domU.te
@@ -0,0 +1,25 @@
+###############################################################################
+#
+# 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)
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..dba4b40
--- /dev/null
+++ b/tools/flask/policy/modules/modules.conf
@@ -0,0 +1,34 @@
+#
+# 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
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..3ee5e75
--- /dev/null
+++ b/tools/flask/policy/modules/xen.te
@@ -0,0 +1,89 @@
+################################################################################
+#
+# 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
+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 };
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 50aa602..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
-    livepatch_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 01/15] flask/policy: split into modules

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:04AM -0400, Daniel De Graaf wrote:
> This makes it easier to enable or disable parts of the XSM policy.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

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

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

Re: [PATCH 01/15] flask/policy: split into modules

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 251 bytes --]

On 6/9/16 9:47 AM, Daniel De Graaf wrote:
> This makes it easier to enable or disable parts of the XSM policy.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Reviewed-by: Doug Goldstein <cardoe@cardoe.com>

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

[PATCH 02/15] flask/policy: split out rules for system_r

[Daniel De Graaf]

When the all_system_role module is enabled, any domain type can be
created using the system_r role, which was the default.  When it is
disabled, domains not using the default types (dom0_t and domU_t) must
use another role such as vm_r.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/modules/all_system_role.te |  8 ++++++++
 tools/flask/policy/modules/domU.te            |  3 +++
 tools/flask/policy/modules/modules.conf       |  5 +++++
 tools/flask/policy/modules/xen.te             | 11 +++--------
 4 files changed, 19 insertions(+), 8 deletions(-)
 create mode 100644 tools/flask/policy/modules/all_system_role.te

diff --git a/tools/flask/policy/modules/all_system_role.te b/tools/flask/policy/modules/all_system_role.te
new file mode 100644
index 0000000..74f870f
--- /dev/null
+++ b/tools/flask/policy/modules/all_system_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/domU.te b/tools/flask/policy/modules/domU.te
index ca5eecd..b77df29 100644
--- a/tools/flask/policy/modules/domU.te
+++ b/tools/flask/policy/modules/domU.te
@@ -23,3 +23,6 @@ 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/modules.conf b/tools/flask/policy/modules/modules.conf
index dba4b40..d875dbf 100644
--- a/tools/flask/policy/modules/modules.conf
+++ b/tools/flask/policy/modules/modules.conf
@@ -32,3 +32,8 @@ nomigrate = on
 
 # Example device policy.  Also see policy/device_contexts.
 nic_dev = on
+
+# This allows any domain type to be created using the system_r role.  When it is
+# disabled, domains not using the default types (dom0_t and domU_t) must use
+# another role (such as vm_r) from the vm_role module.
+all_system_role = on
diff --git a/tools/flask/policy/modules/xen.te b/tools/flask/policy/modules/xen.te
index 3ee5e75..f374dc5 100644
--- a/tools/flask/policy/modules/xen.te
+++ b/tools/flask/policy/modules/xen.te
@@ -78,12 +78,7 @@ neverallow * ~event_type:event { create send status };
 # 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
+# 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 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 };
+role system_r types { xen_type dom0_t };
-- 
2.5.5


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

Re: [PATCH 02/15] flask/policy: split out rules for system_r

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:05AM -0400, Daniel De Graaf wrote:
> When the all_system_role module is enabled, any domain type can be
> created using the system_r role, which was the default.  When it is
> disabled, domains not using the default types (dom0_t and domU_t) must
> use another role such as vm_r.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

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

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

Re: [PATCH 02/15] flask/policy: split out rules for system_r

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 428 bytes --]

On 6/9/16 9:47 AM, Daniel De Graaf wrote:
> When the all_system_role module is enabled, any domain type can be
> created using the system_r role, which was the default.  When it is
> disabled, domains not using the default types (dom0_t and domU_t) must
> use another role such as vm_r.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

[PATCH 03/15] 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/all_system_role.te      |  5 ----
 tools/flask/policy/modules/modules.conf            | 11 +++++--
 .../{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(+), 45 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/all_system_role.te b/tools/flask/policy/modules/all_system_role.te
index 74f870f..3018540 100644
--- a/tools/flask/policy/modules/all_system_role.te
+++ b/tools/flask/policy/modules/all_system_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 d875dbf..9aac6a0 100644
--- a/tools/flask/policy/modules/modules.conf
+++ b/tools/flask/policy/modules/modules.conf
@@ -34,6 +34,13 @@ nomigrate = on
 nic_dev = on
 
 # This allows any domain type to be created using the system_r role.  When it is
-# disabled, domains not using the default types (dom0_t and domU_t) must use
-# another role (such as vm_r) from the vm_role module.
+# disabled, domains not using the default types (dom0_t, domU_t, dm_dom_t) must
+# use another role (such as vm_r from the vm_role module below).
 all_system_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 03/15] flask/policy: move user definitions and constraints into modules

[Konrad Rzeszutek Wilk]

> diff --git a/tools/flask/policy/modules/modules.conf b/tools/flask/policy/modules/modules.conf
> index d875dbf..9aac6a0 100644
> --- a/tools/flask/policy/modules/modules.conf
> +++ b/tools/flask/policy/modules/modules.conf
> @@ -34,6 +34,13 @@ nomigrate = on
>  nic_dev = on
>  
>  # This allows any domain type to be created using the system_r role.  When it is
> -# disabled, domains not using the default types (dom0_t and domU_t) must use
> -# another role (such as vm_r) from the vm_role module.
> +# disabled, domains not using the default types (dom0_t, domU_t, dm_dom_t) must
> +# use another role (such as vm_r from the vm_role module below).
>  all_system_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

So should this be off? As by default we would want all_system_role ?

Ah wait, it can be loaded - even if not used.

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

Re: [PATCH 03/15] flask/policy: move user definitions and constraints into modules

[Daniel De Graaf]

On 06/17/2016 11:28 AM, Konrad Rzeszutek Wilk wrote:
>> diff --git a/tools/flask/policy/modules/modules.conf b/tools/flask/policy/modules/modules.conf
>> index d875dbf..9aac6a0 100644
>> --- a/tools/flask/policy/modules/modules.conf
>> +++ b/tools/flask/policy/modules/modules.conf
>> @@ -34,6 +34,13 @@ nomigrate = on
>>  nic_dev = on
>>
>>  # This allows any domain type to be created using the system_r role.  When it is
>> -# disabled, domains not using the default types (dom0_t and domU_t) must use
>> -# another role (such as vm_r) from the vm_role module.
>> +# disabled, domains not using the default types (dom0_t, domU_t, dm_dom_t) must
>> +# use another role (such as vm_r from the vm_role module below).
>>  all_system_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
>
> So should this be off? As by default we would want all_system_role ?
>
> Ah wait, it can be loaded - even if not used.

Yes, enabling both of these modules gives you flexibility to use either or
both types for domains.  Enabling only one would be useful to enforce its
use, and disabling both doesn't make much sense unless you were adding
another module.

-- 
Daniel De Graaf
National Security Agency

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

Re: [PATCH 03/15] flask/policy: move user definitions and constraints into modules

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 294 bytes --]

On 6/9/16 9:47 AM, Daniel De Graaf wrote:
> This also renames the example users created by vm_role.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>


Reviewed-by: Doug Goldstein <cardoe@cardoe.com>

(Your clarification to Konrad helped me as well)

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

[PATCH 04/15] flask/policy: remove unused support for binary modules

[Daniel De Graaf]

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 .../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 04/15] flask/policy: remove unused support for binary modules

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 240 bytes --]

On 6/9/16 9:47 AM, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Reviewed-by: Doug Goldstein <cardoe@cardoe.com>

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

[PATCH 05/15] 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  | 24 ++++++++++++++++++++++++
 2 files changed, 27 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 9aac6a0..dd10884 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
+
 # This allows any domain type to be created using the system_r role.  When it is
 # disabled, domains not using the default types (dom0_t, domU_t, dm_dom_t) must
 # use another role (such as vm_r from the vm_role module below).
diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te
new file mode 100644
index 0000000..519566a
--- /dev/null
+++ b/tools/flask/policy/modules/xenstore.te
@@ -0,0 +1,24 @@
+################################################################################
+#
+# 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 };
+
+# Xenstore is a utility domain, so it should use the system role
+role system_r types xenstore_t;
-- 
2.5.5


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

Re: [PATCH 05/15] flask/policy: xenstore stubdom policy

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:08AM -0400, Daniel De Graaf wrote:
> 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  | 24 ++++++++++++++++++++++++
>  2 files changed, 27 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 9aac6a0..dd10884 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.

I would also add "(see init-xenstore-domain)."

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

(albeit take it with a grain of salt.  I am just barely touching the SELinux policy
language).

> +xenstore = on
> +
>  # This allows any domain type to be created using the system_r role.  When it is
>  # disabled, domains not using the default types (dom0_t, domU_t, dm_dom_t) must
>  # use another role (such as vm_r from the vm_role module below).
> diff --git a/tools/flask/policy/modules/xenstore.te b/tools/flask/policy/modules/xenstore.te
> new file mode 100644
> index 0000000..519566a
> --- /dev/null
> +++ b/tools/flask/policy/modules/xenstore.te
> @@ -0,0 +1,24 @@
> +################################################################################
> +#
> +# 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 };
> +
> +# Xenstore is a utility domain, so it should use the system role
> +role system_r types xenstore_t;
> -- 
> 2.5.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [PATCH 05/15] flask/policy: xenstore stubdom policy

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 274 bytes --]

On 6/9/16 9:47 AM, Daniel De Graaf wrote:
> 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>

Reviewed-by: Doug Goldstein <cardoe@cardoe.com>

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

[PATCH 06/15] flask/policy: remove unused example

[Daniel De Graaf]

The access vectors defined here have never been used by xenstore.

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

diff --git a/tools/flask/policy/policy/access_vectors b/tools/flask/policy/policy/access_vectors
index 4fd61f1..d9c69c0 100644
--- a/tools/flask/policy/policy/access_vectors
+++ b/tools/flask/policy/policy/access_vectors
@@ -1,24 +1,5 @@
 # Locally defined access vectors
 #
-# Define access vectors for the security classes defined in security_classes
+# Define access vectors for the security classes defined in security_classes.
+# Access vectors defined in this file should not be used by the hypervisor.
 #
-
-# 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
-}
diff --git a/tools/flask/policy/policy/security_classes b/tools/flask/policy/policy/security_classes
index 56595e8..0f0f9f3 100644
--- a/tools/flask/policy/policy/security_classes
+++ b/tools/flask/policy/policy/security_classes
@@ -5,4 +5,3 @@
 # security policy.
 #
 # Access vectors for these classes must be defined in the access_vectors file.
-class xenstore
-- 
2.5.5


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

Re: [PATCH 06/15] flask/policy: remove unused example

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:09AM -0400, Daniel De Graaf wrote:
> The access vectors defined here have never been used by xenstore.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  tools/flask/policy/policy/access_vectors   | 23 ++---------------------
>  tools/flask/policy/policy/security_classes |  1 -
>  2 files changed, 2 insertions(+), 22 deletions(-)
> 
> diff --git a/tools/flask/policy/policy/access_vectors b/tools/flask/policy/policy/access_vectors
> index 4fd61f1..d9c69c0 100644
> --- a/tools/flask/policy/policy/access_vectors
> +++ b/tools/flask/policy/policy/access_vectors
> @@ -1,24 +1,5 @@
>  # Locally defined access vectors
>  #
> -# Define access vectors for the security classes defined in security_classes
> +# Define access vectors for the security classes defined in security_classes.
> +# Access vectors defined in this file should not be used by the hypervisor.
>  #
> -
> -# 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
> -}
> diff --git a/tools/flask/policy/policy/security_classes b/tools/flask/policy/policy/security_classes
> index 56595e8..0f0f9f3 100644
> --- a/tools/flask/policy/policy/security_classes
> +++ b/tools/flask/policy/policy/security_classes
> @@ -5,4 +5,3 @@
>  # security policy.
>  #
>  # Access vectors for these classes must be defined in the access_vectors file.
> -class xenstore
> -- 
> 2.5.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [PATCH 06/15] flask/policy: remove unused example

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 250 bytes --]

On 6/9/16 9:47 AM, Daniel De Graaf wrote:
> The access vectors defined here have never been used by xenstore.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Reviewed-by: Doug Goldstein <cardoe@cardoe.com>

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

[PATCH 07/15] flask: unify {get, set}vcpucontext permissions

[Daniel De Graaf]

These permissions were initially split because they were in separate
domctls, but this split is very unlikely to actually provide security
benefits: it would require a carefully contrived situation for a domain
to both need access to one type of CPU register and also need to be
prohibited from accessing another type.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/modules/dom0.te  |  1 -
 tools/flask/policy/modules/xen.if   |  7 +++----
 xen/xsm/flask/hooks.c               | 20 ++++++--------------
 xen/xsm/flask/policy/access_vectors | 16 ++++++----------
 4 files changed, 15 insertions(+), 29 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index ef6a986..d228b24 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -34,7 +34,6 @@ 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 {
diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
index 00d1bbb..fd96303 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -47,9 +47,8 @@ define(`declare_build_label', `
 
 define(`create_domain_common', `
 	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
-			getdomaininfo hypercall setvcpucontext setextvcpucontext
-			getscheduler getvcpuinfo getvcpuextstate getaddrsize
-			getaffinity setaffinity setvcpuextstate };
+			getdomaininfo hypercall setvcpucontext getscheduler
+			getvcpuinfo getaddrsize getaffinity setaffinity };
 	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
 			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
 			psr_cmt_op psr_cat_op soft_reset };
@@ -94,7 +93,7 @@ define(`migrate_domain_out', `
 	allow $1 domxen_t:mmu map_read;
 	allow $1 $2:hvm { gethvmc getparam irqlevel };
 	allow $1 $2:mmu { stat pageinfo map_read };
-	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
+	allow $1 $2:domain { getaddrsize getvcpucontext pause destroy };
 	allow $1 $2:domain2 gettsc;
 	allow $1 $2:shadow { enable disable logdirty };
 ')
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 20d46c8..a8d45e7 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -630,10 +630,16 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_setdomainhandle:
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE);
 
+    case XEN_DOMCTL_set_ext_vcpucontext:
+    case XEN_DOMCTL_set_vcpu_msrs:
     case XEN_DOMCTL_setvcpucontext:
+    case XEN_DOMCTL_setvcpuextstate:
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT);
 
+    case XEN_DOMCTL_get_ext_vcpucontext:
+    case XEN_DOMCTL_get_vcpu_msrs:
     case XEN_DOMCTL_getvcpucontext:
+    case XEN_DOMCTL_getvcpuextstate:
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT);
 
     case XEN_DOMCTL_getvcpuinfo:
@@ -675,20 +681,6 @@ static int flask_domctl(struct domain *d, int cmd)
     case XEN_DOMCTL_pin_mem_cacheattr:
         return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
 
-    case XEN_DOMCTL_set_ext_vcpucontext:
-    case XEN_DOMCTL_set_vcpu_msrs:
-        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT);
-
-    case XEN_DOMCTL_get_ext_vcpucontext:
-    case XEN_DOMCTL_get_vcpu_msrs:
-        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT);
-
-    case XEN_DOMCTL_setvcpuextstate:
-        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUEXTSTATE);
-
-    case XEN_DOMCTL_getvcpuextstate:
-        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUEXTSTATE);
-
     case XEN_DOMCTL_sendtrigger:
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
 
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 3d29042..7e69ede 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -111,6 +111,9 @@ class xen2
 class domain
 {
 # XEN_DOMCTL_setvcpucontext
+# XEN_DOMCTL_setvcpuextstate
+# XEN_DOMCTL_set_ext_vcpucontext
+# XEN_DOMCTL_set_vcpu_msrs
     setvcpucontext
 # XEN_DOMCTL_pausedomain
     pause
@@ -142,6 +145,9 @@ class domain
 # XEN_DOMCTL_getvcpuinfo
     getvcpuinfo
 # XEN_DOMCTL_getvcpucontext
+# XEN_DOMCTL_get_ext_vcpucontext
+# XEN_DOMCTL_getvcpuextstate
+# XEN_DOMCTL_get_vcpu_msrs
     getvcpucontext
 # XEN_DOMCTL_max_mem
     setdomainmaxmem
@@ -166,16 +172,6 @@ class domain
     getaddrsize
 # XEN_DOMCTL_sendtrigger
     trigger
-# XEN_DOMCTL_get_ext_vcpucontext
-# XEN_DOMCTL_set_vcpu_msrs
-    getextvcpucontext
-# XEN_DOMCTL_set_ext_vcpucontext
-# XEN_DOMCTL_get_vcpu_msrs
-    setextvcpucontext
-# XEN_DOMCTL_getvcpuextstate
-    getvcpuextstate
-# XEN_DOMCTL_setvcpuextstate
-    setvcpuextstate
 # XENMEM_get_pod_target
     getpodtarget
 # XENMEM_set_pod_target
-- 
2.5.5


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

Re: [PATCH 07/15] flask: unify {get, set}vcpucontext permissions

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:10AM -0400, Daniel De Graaf wrote:
> These permissions were initially split because they were in separate
> domctls, but this split is very unlikely to actually provide security
> benefits: it would require a carefully contrived situation for a domain
> to both need access to one type of CPU register and also need to be
> prohibited from accessing another type.
> 

CC-ing Andrew as I believe has been looking in this code when doing
miration and may have an opinion on this.

> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  tools/flask/policy/modules/dom0.te  |  1 -
>  tools/flask/policy/modules/xen.if   |  7 +++----
>  xen/xsm/flask/hooks.c               | 20 ++++++--------------
>  xen/xsm/flask/policy/access_vectors | 16 ++++++----------
>  4 files changed, 15 insertions(+), 29 deletions(-)
> 
> diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
> index ef6a986..d228b24 100644
> --- a/tools/flask/policy/modules/dom0.te
> +++ b/tools/flask/policy/modules/dom0.te
> @@ -34,7 +34,6 @@ 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 {
> diff --git a/tools/flask/policy/modules/xen.if b/tools/flask/policy/modules/xen.if
> index 00d1bbb..fd96303 100644
> --- a/tools/flask/policy/modules/xen.if
> +++ b/tools/flask/policy/modules/xen.if
> @@ -47,9 +47,8 @@ define(`declare_build_label', `
>  
>  define(`create_domain_common', `
>  	allow $1 $2:domain { create max_vcpus setdomainmaxmem setaddrsize
> -			getdomaininfo hypercall setvcpucontext setextvcpucontext
> -			getscheduler getvcpuinfo getvcpuextstate getaddrsize
> -			getaffinity setaffinity setvcpuextstate };
> +			getdomaininfo hypercall setvcpucontext getscheduler
> +			getvcpuinfo getaddrsize getaffinity setaffinity };
>  	allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
>  			set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
>  			psr_cmt_op psr_cat_op soft_reset };
> @@ -94,7 +93,7 @@ define(`migrate_domain_out', `
>  	allow $1 domxen_t:mmu map_read;
>  	allow $1 $2:hvm { gethvmc getparam irqlevel };
>  	allow $1 $2:mmu { stat pageinfo map_read };
> -	allow $1 $2:domain { getaddrsize getvcpucontext getextvcpucontext getvcpuextstate pause destroy };
> +	allow $1 $2:domain { getaddrsize getvcpucontext pause destroy };
>  	allow $1 $2:domain2 gettsc;
>  	allow $1 $2:shadow { enable disable logdirty };
>  ')
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 20d46c8..a8d45e7 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -630,10 +630,16 @@ static int flask_domctl(struct domain *d, int cmd)
>      case XEN_DOMCTL_setdomainhandle:
>          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETDOMAINHANDLE);
>  
> +    case XEN_DOMCTL_set_ext_vcpucontext:
> +    case XEN_DOMCTL_set_vcpu_msrs:
>      case XEN_DOMCTL_setvcpucontext:
> +    case XEN_DOMCTL_setvcpuextstate:
>          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUCONTEXT);
>  
> +    case XEN_DOMCTL_get_ext_vcpucontext:
> +    case XEN_DOMCTL_get_vcpu_msrs:
>      case XEN_DOMCTL_getvcpucontext:
> +    case XEN_DOMCTL_getvcpuextstate:
>          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUCONTEXT);
>  
>      case XEN_DOMCTL_getvcpuinfo:
> @@ -675,20 +681,6 @@ static int flask_domctl(struct domain *d, int cmd)
>      case XEN_DOMCTL_pin_mem_cacheattr:
>          return current_has_perm(d, SECCLASS_HVM, HVM__CACHEATTR);
>  
> -    case XEN_DOMCTL_set_ext_vcpucontext:
> -    case XEN_DOMCTL_set_vcpu_msrs:
> -        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETEXTVCPUCONTEXT);
> -
> -    case XEN_DOMCTL_get_ext_vcpucontext:
> -    case XEN_DOMCTL_get_vcpu_msrs:
> -        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETEXTVCPUCONTEXT);
> -
> -    case XEN_DOMCTL_setvcpuextstate:
> -        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__SETVCPUEXTSTATE);
> -
> -    case XEN_DOMCTL_getvcpuextstate:
> -        return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETVCPUEXTSTATE);
> -
>      case XEN_DOMCTL_sendtrigger:
>          return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
>  
> diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
> index 3d29042..7e69ede 100644
> --- a/xen/xsm/flask/policy/access_vectors
> +++ b/xen/xsm/flask/policy/access_vectors
> @@ -111,6 +111,9 @@ class xen2
>  class domain
>  {
>  # XEN_DOMCTL_setvcpucontext
> +# XEN_DOMCTL_setvcpuextstate
> +# XEN_DOMCTL_set_ext_vcpucontext
> +# XEN_DOMCTL_set_vcpu_msrs
>      setvcpucontext
>  # XEN_DOMCTL_pausedomain
>      pause
> @@ -142,6 +145,9 @@ class domain
>  # XEN_DOMCTL_getvcpuinfo
>      getvcpuinfo
>  # XEN_DOMCTL_getvcpucontext
> +# XEN_DOMCTL_get_ext_vcpucontext
> +# XEN_DOMCTL_getvcpuextstate
> +# XEN_DOMCTL_get_vcpu_msrs
>      getvcpucontext
>  # XEN_DOMCTL_max_mem
>      setdomainmaxmem
> @@ -166,16 +172,6 @@ class domain
>      getaddrsize
>  # XEN_DOMCTL_sendtrigger
>      trigger
> -# XEN_DOMCTL_get_ext_vcpucontext
> -# XEN_DOMCTL_set_vcpu_msrs
> -    getextvcpucontext
> -# XEN_DOMCTL_set_ext_vcpucontext
> -# XEN_DOMCTL_get_vcpu_msrs
> -    setextvcpucontext
> -# XEN_DOMCTL_getvcpuextstate
> -    getvcpuextstate
> -# XEN_DOMCTL_setvcpuextstate
> -    setvcpuextstate
>  # XENMEM_get_pod_target
>      getpodtarget
>  # XENMEM_set_pod_target
> -- 
> 2.5.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[PATCH 08/15] flask: remove unused secondary context in ocontext

[Daniel De Graaf]

This field was originally used in Linux for a default message code for
network interfaces.  It has never been used in Xen, so remove it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/ss/policydb.c | 1 -
 xen/xsm/flask/ss/policydb.h | 4 ++--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index eebfe9c..8aa88c1 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -639,7 +639,6 @@ static int (*destroy_f[SYM_NUM]) (void *key, void *datum, void *datap) =
 static void ocontext_destroy(struct ocontext *c, int i)
 {
     context_destroy(&c->context[0]);
-    context_destroy(&c->context[1]);
     if ( i == OCON_ISID || i == OCON_DTREE )
         xfree(c->u.name);
     xfree(c);
diff --git a/xen/xsm/flask/ss/policydb.h b/xen/xsm/flask/ss/policydb.h
index 30be71a..50e22f3 100644
--- a/xen/xsm/flask/ss/policydb.h
+++ b/xen/xsm/flask/ss/policydb.h
@@ -158,8 +158,8 @@ struct ocontext {
                 u64 high_iomem;
         } iomem;
     } u;
-    struct context context[2];    /* security context(s) */
-    u32 sid[2];    /* SID(s) */
+    struct context context[1];    /* security context(s) */
+    u32 sid[1];    /* SID(s) */
     struct ocontext *next;
 };
 
-- 
2.5.5


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

Re: [PATCH 08/15] flask: remove unused secondary context in ocontext

[Jan Beulich]

>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/xsm/flask/ss/policydb.h
> +++ b/xen/xsm/flask/ss/policydb.h
> @@ -158,8 +158,8 @@ struct ocontext {
>                  u64 high_iomem;
>          } iomem;
>      } u;
> -    struct context context[2];    /* security context(s) */
> -    u32 sid[2];    /* SID(s) */
> +    struct context context[1];    /* security context(s) */
> +    u32 sid[1];    /* SID(s) */

Is keeping them be arrays useful for anything?

Jan


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

Re: [PATCH 08/15] flask: remove unused secondary context in ocontext

[Daniel De Graaf]

On 06/09/2016 12:01 PM, Jan Beulich wrote:
>>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
>> --- a/xen/xsm/flask/ss/policydb.h
>> +++ b/xen/xsm/flask/ss/policydb.h
>> @@ -158,8 +158,8 @@ struct ocontext {
>>                  u64 high_iomem;
>>          } iomem;
>>      } u;
>> -    struct context context[2];    /* security context(s) */
>> -    u32 sid[2];    /* SID(s) */
>> +    struct context context[1];    /* security context(s) */
>> +    u32 sid[1];    /* SID(s) */
>
> Is keeping them be arrays useful for anything?
>
> Jan
>
>
No, it was just more code churn to convert them to fields.

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

[PATCH 09/15] flask: remove unused AVC callback functions

[Daniel De Graaf]

These callbacks are not used in Xen.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/avc.c         | 97 ++-------------------------------------------
 xen/xsm/flask/include/avc.h | 13 ------
 2 files changed, 4 insertions(+), 106 deletions(-)

diff --git a/xen/xsm/flask/avc.c b/xen/xsm/flask/avc.c
index 7764379..a3e6108 100644
--- a/xen/xsm/flask/avc.c
+++ b/xen/xsm/flask/avc.c
@@ -86,18 +86,6 @@ struct avc_cache {
     u32            latest_notif;    /* latest revocation notification */
 };
 
-struct avc_callback_node {
-    int (*callback) (u32 event, u32 ssid, u32 tsid,
-                     u16 tclass, u32 perms,
-                     u32 *out_retained);
-    u32 events;
-    u32 ssid;
-    u32 tsid;
-    u16 tclass;
-    u32 perms;
-    struct avc_callback_node *next;
-};
-
 /* Exported via Flask hypercall */
 unsigned int avc_cache_threshold = AVC_DEF_CACHE_THRESHOLD;
 
@@ -106,7 +94,6 @@ DEFINE_PER_CPU(struct avc_cache_stats, avc_cache_stats);
 #endif
 
 static struct avc_cache avc_cache;
-static struct avc_callback_node *avc_callbacks;
 
 static DEFINE_RCU_READ_LOCK(avc_rcu_lock);
 
@@ -616,46 +603,6 @@ void avc_audit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
 }
 
 /**
- * avc_add_callback - Register a callback for security events.
- * @callback: callback function
- * @events: security events
- * @ssid: source security identifier or %SECSID_WILD
- * @tsid: target security identifier or %SECSID_WILD
- * @tclass: target security class
- * @perms: permissions
- *
- * Register a callback function for events in the set @events
- * related to the SID pair (@ssid, @tsid) and
- * and the permissions @perms, interpreting
- * @perms based on @tclass.  Returns %0 on success or
- * -%ENOMEM if insufficient memory exists to add the callback.
- */
-int avc_add_callback(int (*callback)(u32 event, u32 ssid, u32 tsid, u16 tclass,
-                                     u32 perms, u32 *out_retained), u32 events, u32 ssid, u32 tsid,
-                     u16 tclass, u32 perms)
-{
-    struct avc_callback_node *c;
-    int rc = 0;
-
-    c = xmalloc(struct avc_callback_node);
-    if ( !c )
-    {
-        rc = -ENOMEM;
-        goto out;
-    }
-
-    c->callback = callback;
-    c->events = events;
-    c->ssid = ssid;
-    c->tsid = tsid;
-    c->perms = perms;
-    c->next = avc_callbacks;
-    avc_callbacks = c;
- out:
-    return rc;
-}
-
-/**
  * avc_update_node Update an AVC entry
  * @event : Updating event
  * @perms : Permission mask bits
@@ -666,7 +613,7 @@ int avc_add_callback(int (*callback)(u32 event, u32 ssid, u32 tsid, u16 tclass,
  * otherwise, this function update the AVC entry. The original AVC-entry object
  * will release later by RCU.
  */
-static int avc_update_node(u32 event, u32 perms, u32 ssid, u32 tsid, u16 tclass,
+static int avc_update_node(u32 perms, u32 ssid, u32 tsid, u16 tclass,
                            u32 seqno)
 {
     int hvalue, rc = 0;
@@ -715,28 +662,7 @@ static int avc_update_node(u32 event, u32 perms, u32 ssid, u32 tsid, u16 tclass,
 
     avc_node_populate(node, ssid, tsid, tclass, &orig->ae.avd);
 
-    switch ( event )
-    {
-    case AVC_CALLBACK_GRANT:
-        node->ae.avd.allowed |= perms;
-        break;
-    case AVC_CALLBACK_TRY_REVOKE:
-    case AVC_CALLBACK_REVOKE:
-        node->ae.avd.allowed &= ~perms;
-        break;
-    case AVC_CALLBACK_AUDITALLOW_ENABLE:
-        node->ae.avd.auditallow |= perms;
-        break;
-    case AVC_CALLBACK_AUDITALLOW_DISABLE:
-        node->ae.avd.auditallow &= ~perms;
-        break;
-    case AVC_CALLBACK_AUDITDENY_ENABLE:
-        node->ae.avd.auditdeny |= perms;
-        break;
-    case AVC_CALLBACK_AUDITDENY_DISABLE:
-        node->ae.avd.auditdeny &= ~perms;
-        break;
-    }
+    node->ae.avd.allowed |= perms;
     avc_node_replace(node, orig);
  out_unlock:
     spin_unlock_irqrestore(lock, flag);
@@ -750,8 +676,7 @@ static int avc_update_node(u32 event, u32 perms, u32 ssid, u32 tsid, u16 tclass,
  */
 int avc_ss_reset(u32 seqno)
 {
-    struct avc_callback_node *c;
-    int i, rc = 0, tmprc;
+    int i, rc = 0;
     unsigned long flag;
     struct avc_node *node;
     struct hlist_head *head;
@@ -771,19 +696,6 @@ int avc_ss_reset(u32 seqno)
         spin_unlock_irqrestore(lock, flag);
     }
     
-    for ( c = avc_callbacks; c; c = c->next )
-    {
-        if ( c->events & AVC_CALLBACK_RESET )
-        {
-            tmprc = c->callback(AVC_CALLBACK_RESET,
-                                0, 0, 0, 0, NULL);
-            /* save the first error encountered for the return
-               value and continue processing the callbacks */
-            if ( !rc )
-                rc = tmprc;
-        }
-    }
-
     avc_latest_notif_update(seqno, 0);
     return rc;
 }
@@ -845,8 +757,7 @@ int avc_has_perm_noaudit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
     if ( denied )
     {
         if ( !flask_enforcing || (avd->flags & AVD_FLAGS_PERMISSIVE) )
-            avc_update_node(AVC_CALLBACK_GRANT,requested,
-                            ssid,tsid,tclass,avd->seqno);
+            avc_update_node(requested, ssid,tsid,tclass,avd->seqno);
         else
             rc = -EACCES;
     }
diff --git a/xen/xsm/flask/include/avc.h b/xen/xsm/flask/include/avc.h
index 729856e..c153c8e 100644
--- a/xen/xsm/flask/include/avc.h
+++ b/xen/xsm/flask/include/avc.h
@@ -90,19 +90,6 @@ int avc_has_perm_noaudit(u32 ssid, u32 tsid, u16 tclass, u32 requested,
 int avc_has_perm(u32 ssid, u32 tsid, u16 tclass, u32 requested,
                                              struct avc_audit_data *auditdata);
 
-#define AVC_CALLBACK_GRANT        1
-#define AVC_CALLBACK_TRY_REVOKE        2
-#define AVC_CALLBACK_REVOKE        4
-#define AVC_CALLBACK_RESET        8
-#define AVC_CALLBACK_AUDITALLOW_ENABLE    16
-#define AVC_CALLBACK_AUDITALLOW_DISABLE    32
-#define AVC_CALLBACK_AUDITDENY_ENABLE    64
-#define AVC_CALLBACK_AUDITDENY_DISABLE    128
-
-int avc_add_callback(int (*callback)(u32 event, u32 ssid, u32 tsid,
-                        u16 tclass, u32 perms, u32 *out_retained), u32 events, 
-                                    u32 ssid, u32 tsid, u16 tclass, u32 perms);
-
 /* Exported to selinuxfs */
 struct xen_flask_hash_stats;
 int avc_get_hash_stats(struct xen_flask_hash_stats *arg);
-- 
2.5.5


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

[PATCH 10/15] flask: remove xen_flask_userlist operation

[Daniel De Graaf]

This operation has no known users, and is primarily useful when an MLS
policy is in use (which has never been shipped with Xen).  The
information it provides is only useful for policy analysis and does not
actually depend on hypervisor state, so an application that needs it
should compute the results without needing to involve the hypervisor.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/modules/dom0.te  |   2 +-
 xen/include/public/xsm/flask_op.h   |  17 +-----
 xen/include/xlat.lst                |   1 -
 xen/xsm/flask/flask_op.c            |  42 --------------
 xen/xsm/flask/include/security.h    |   2 -
 xen/xsm/flask/policy/access_vectors |   2 -
 xen/xsm/flask/ss/mls.c              |  49 ----------------
 xen/xsm/flask/ss/mls.h              |   3 -
 xen/xsm/flask/ss/services.c         | 111 ------------------------------------
 9 files changed, 2 insertions(+), 227 deletions(-)

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index d228b24..2d982d9 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -47,7 +47,7 @@ allow dom0_t dom0_t:resource { add remove };
 # 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
+	compute_av compute_create compute_member compute_relabel
 };
 
 # Allow string/SID conversions (for "xl list -Z" and similar)
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index c76359c..cf53f2c 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -70,20 +70,6 @@ struct xen_flask_transition {
     uint32_t newsid;
 };
 
-struct xen_flask_userlist {
-    /* IN: starting SID for list */
-    uint32_t start_sid;
-    /* IN: size of user string and output buffer
-     * OUT: number of SIDs returned */
-    uint32_t size;
-    union {
-        /* IN: user to enumerate SIDs */
-        XEN_GUEST_HANDLE(char) user;
-        /* OUT: SID list */
-        XEN_GUEST_HANDLE(uint32) sids;
-    } u;
-};
-
 struct xen_flask_boolean {
     /* IN/OUT: numeric identifier for boolean [GET/SET]
      * If -1, name will be used and bool_id will be filled in. */
@@ -167,7 +153,7 @@ struct xen_flask_op {
 #define FLASK_ACCESS            6
 #define FLASK_CREATE            7
 #define FLASK_RELABEL           8
-#define FLASK_USER              9
+#define FLASK_USER              9  /* No longer implemented */
 #define FLASK_POLICYVERS        10
 #define FLASK_GETBOOL           11
 #define FLASK_SETBOOL           12
@@ -193,7 +179,6 @@ struct xen_flask_op {
         struct xen_flask_access access;
         /* FLASK_CREATE, FLASK_RELABEL, FLASK_MEMBER */
         struct xen_flask_transition transition;
-        struct xen_flask_userlist userlist;
         /* FLASK_GETBOOL, FLASK_SETBOOL */
         struct xen_flask_boolean boolean;
         struct xen_flask_setavc_threshold setavc_threshold;
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 23befb3..801a1c1 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -129,4 +129,3 @@
 ?	flask_setenforce		xsm/flask_op.h
 !	flask_sid_context		xsm/flask_op.h
 ?	flask_transition		xsm/flask_op.h
-!	flask_userlist			xsm/flask_op.h
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index ea903a7..3ad4bdc 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -86,43 +86,6 @@ static int domain_has_security(struct domain *d, u32 perms)
                         perms, NULL);
 }
 
-#endif /* COMPAT */
-
-static int flask_security_user(struct xen_flask_userlist *arg)
-{
-    char *user;
-    u32 *sids;
-    u32 nsids;
-    int rv;
-
-    rv = domain_has_security(current->domain, SECURITY__COMPUTE_USER);
-    if ( rv )
-        return rv;
-
-    user = safe_copy_string_from_guest(arg->u.user, arg->size, PAGE_SIZE);
-    if ( IS_ERR(user) )
-        return PTR_ERR(user);
-
-    rv = security_get_user_sids(arg->start_sid, user, &sids, &nsids);
-    if ( rv < 0 )
-        goto out;
-
-    if ( nsids * sizeof(sids[0]) > arg->size )
-        nsids = arg->size / sizeof(sids[0]);
-
-    arg->size = nsids;
-
-    if ( _copy_to_guest(arg->u.sids, sids, nsids) )
-        rv = -EFAULT;
-
-    xfree(sids);
- out:
-    xfree(user);
-    return rv;
-}
-
-#ifndef COMPAT
-
 static int flask_security_relabel(struct xen_flask_transition *arg)
 {
     int rv;
@@ -714,10 +677,6 @@ ret_t do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op)
         rv = flask_security_relabel(&op.u.transition);
         break;
 
-    case FLASK_USER:
-        rv = flask_security_user(&op.u.userlist);
-        break;
-
     case FLASK_POLICYVERS:
         rv = POLICYDB_VERSION_MAX;
         break;
@@ -831,7 +790,6 @@ CHECK_flask_transition;
 #define flask_security_load compat_security_load
 
 #define xen_flask_userlist compat_flask_userlist
-#define flask_security_user compat_security_user
 
 #define xen_flask_sid_context compat_flask_sid_context
 #define flask_security_context compat_security_context
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 34bbe62..2b00177 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -78,8 +78,6 @@ int security_sid_to_context(u32 sid, char **scontext, u32 *scontext_len);
 
 int security_context_to_sid(char *scontext, u32 scontext_len, u32 *out_sid);
 
-int security_get_user_sids(u32 callsid, char *username, u32 **sids, u32 *nel);
-
 int security_irq_sid(int pirq, u32 *out_sid);
 
 int security_iomem_sid(unsigned long, u32 *out_sid);
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 7e69ede..49c9a9e 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -484,8 +484,6 @@ class security
     load_policy
 # use the security server to compute an object relabel
     compute_relabel
-# use the security server to list the SIDs reachable by a given user
-    compute_user
 # allow switching between enforcing and permissive mode
     setenforce
 # allow changing policy booleans
diff --git a/xen/xsm/flask/ss/mls.c b/xen/xsm/flask/ss/mls.c
index bbe7a49..f2fa560 100644
--- a/xen/xsm/flask/ss/mls.c
+++ b/xen/xsm/flask/ss/mls.c
@@ -396,55 +396,6 @@ static inline int mls_range_set(struct context *context,
     return rc;
 }
 
-int mls_setup_user_range(struct context *fromcon, struct user_datum *user,
-                                                        struct context *usercon)
-{
-    if ( flask_mls_enabled )
-    {
-        struct mls_level *fromcon_sen = &(fromcon->range.level[0]);
-        struct mls_level *fromcon_clr = &(fromcon->range.level[1]);
-        struct mls_level *user_low = &(user->range.level[0]);
-        struct mls_level *user_clr = &(user->range.level[1]);
-        struct mls_level *user_def = &(user->dfltlevel);
-        struct mls_level *usercon_sen = &(usercon->range.level[0]);
-        struct mls_level *usercon_clr = &(usercon->range.level[1]);
-
-        /* Honor the user's default level if we can */
-        if ( mls_level_between(user_def, fromcon_sen, fromcon_clr) )
-        {
-            *usercon_sen = *user_def;
-        }
-        else if ( mls_level_between(fromcon_sen, user_def, user_clr) )
-        {
-            *usercon_sen = *fromcon_sen;
-        }
-        else if ( mls_level_between(fromcon_clr, user_low, user_def) )
-        {
-            *usercon_sen = *user_low;
-        }
-        else
-            return -EINVAL;
-
-        /* Lower the clearance of available contexts
-           if the clearance of "fromcon" is lower than
-           that of the user's default clearance (but
-           only if the "fromcon" clearance dominates
-           the user's computed sensitivity level) */
-        if ( mls_level_dom(user_clr, fromcon_clr) )
-        {
-            *usercon_clr = *fromcon_clr;
-        }
-        else if ( mls_level_dom(fromcon_clr, user_clr) )
-        {
-            *usercon_clr = *user_clr;
-        }
-        else
-            return -EINVAL;
-    }
-
-    return 0;
-}
-
 /*
  * Convert the MLS fields in the security context
  * structure `c' from the values specified in the
diff --git a/xen/xsm/flask/ss/mls.h b/xen/xsm/flask/ss/mls.h
index b3a015e..39572bd 100644
--- a/xen/xsm/flask/ss/mls.h
+++ b/xen/xsm/flask/ss/mls.h
@@ -32,8 +32,5 @@ int mls_convert_context(struct policydb *oldp, struct policydb *newp,
 int mls_compute_sid(struct context *scontext, struct context *tcontext,
                         u16 tclass, u32 specified, struct context *newcontext);
 
-int mls_setup_user_range(struct context *fromcon, struct user_datum *user,
-                                                     struct context *usercon);
-
 #endif    /* _SS_MLS_H */
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 9da358b..c9b27a0 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1721,117 +1721,6 @@ out:
     return rc;
 }
 
-#define SIDS_NEL 25
-
-/**
- * security_get_user_sids - Obtain reachable SIDs for a user.
- * @fromsid: starting SID
- * @username: username
- * @sids: array of reachable SIDs for user
- * @nel: number of elements in @sids
- *
- * Generate the set of SIDs for legal security contexts
- * for a given user that can be reached by @fromsid.
- * Set *@sids to point to a dynamically allocated
- * array containing the set of SIDs.  Set *@nel to the
- * number of elements in the array.
- */
-
-int security_get_user_sids(u32 fromsid, char *username, u32 **sids, u32 *nel)
-{
-    struct context *fromcon, usercon;
-    u32 *mysids, *mysids2, sid;
-    u32 mynel = 0, maxnel = SIDS_NEL;
-    struct user_datum *user;
-    struct role_datum *role;
-    struct av_decision avd;
-    struct ebitmap_node *rnode, *tnode;
-    int rc = 0, i, j;
-
-    if ( !ss_initialized )
-    {
-        *sids = NULL;
-        *nel = 0;
-        goto out;
-    }
-
-    POLICY_RDLOCK;
-
-    fromcon = sidtab_search(&sidtab, fromsid);
-    if ( !fromcon )
-    {
-        rc = -EINVAL;
-        goto out_unlock;
-    }
-
-    user = hashtab_search(policydb.p_users.table, username);
-    if ( !user )
-    {
-        rc = -EINVAL;
-        goto out_unlock;
-    }
-    usercon.user = user->value;
-
-    mysids = xzalloc_array(u32, maxnel);
-    if ( !mysids )
-    {
-        rc = -ENOMEM;
-        goto out_unlock;
-    }
-
-    ebitmap_for_each_positive_bit(&user->roles, rnode, i)
-    {
-        role = policydb.role_val_to_struct[i];
-        usercon.role = i+1;
-        ebitmap_for_each_positive_bit(&role->types, tnode, j) {
-            usercon.type = j+1;
-
-            if ( mls_setup_user_range(fromcon, user, &usercon) )
-                continue;
-
-            rc = context_struct_compute_av(fromcon, &usercon,
-                               SECCLASS_DOMAIN,
-                               DOMAIN__TRANSITION,
-                               &avd);
-            if ( rc ||  !(avd.allowed & DOMAIN__TRANSITION) )
-                continue;
-            rc = sidtab_context_to_sid(&sidtab, &usercon, &sid);
-            if ( rc )
-            {
-                xfree(mysids);
-                goto out_unlock;
-            }
-            if ( mynel < maxnel )
-            {
-                mysids[mynel++] = sid;
-            }
-            else
-            {
-                maxnel += SIDS_NEL;
-                mysids2 = xzalloc_array(u32, maxnel);
-                if ( !mysids2 )
-                {
-                    rc = -ENOMEM;
-                    xfree(mysids);
-                    goto out_unlock;
-                }
-                memcpy(mysids2, mysids, mynel * sizeof(*mysids2));
-                xfree(mysids);
-                mysids = mysids2;
-                mysids[mynel++] = sid;
-            }
-        }
-    }
-
-    *sids = mysids;
-    *nel = mynel;
-
-out_unlock:
-    POLICY_RDUNLOCK;
-out:
-    return rc;
-}
-
 int security_devicetree_sid(const char *path, u32 *out_sid)
 {
     struct ocontext *c;
-- 
2.5.5


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

Re: [PATCH 10/15] flask: remove xen_flask_userlist operation

[Jan Beulich]

>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/include/public/xsm/flask_op.h
> +++ b/xen/include/public/xsm/flask_op.h
> @@ -70,20 +70,6 @@ struct xen_flask_transition {
>      uint32_t newsid;
>  };
>  
> -struct xen_flask_userlist {
> -    /* IN: starting SID for list */
> -    uint32_t start_sid;
> -    /* IN: size of user string and output buffer
> -     * OUT: number of SIDs returned */
> -    uint32_t size;
> -    union {
> -        /* IN: user to enumerate SIDs */
> -        XEN_GUEST_HANDLE(char) user;
> -        /* OUT: SID list */
> -        XEN_GUEST_HANDLE(uint32) sids;
> -    } u;
> -};

No known users or not, we don't normally allow breaking code that
may be consuming any of our public headers. I.e. conventionally,
for interfaces not restricted to the tool stack we keep everything,
but guard it with a __XEN_INTERFACE_VERSION__ conditional.

Whether making an exception here is okay I'm not certain; in any
event would you imo need to bump XEN_FLASK_INTERFACE_VERSION.

Jan


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

Re: [PATCH 10/15] flask: remove xen_flask_userlist operation

[Daniel De Graaf]

On 06/09/2016 12:07 PM, Jan Beulich wrote:
>>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
>> --- a/xen/include/public/xsm/flask_op.h
>> +++ b/xen/include/public/xsm/flask_op.h
>> @@ -70,20 +70,6 @@ struct xen_flask_transition {
>>      uint32_t newsid;
>>  };
>>
>> -struct xen_flask_userlist {
>> -    /* IN: starting SID for list */
>> -    uint32_t start_sid;
>> -    /* IN: size of user string and output buffer
>> -     * OUT: number of SIDs returned */
>> -    uint32_t size;
>> -    union {
>> -        /* IN: user to enumerate SIDs */
>> -        XEN_GUEST_HANDLE(char) user;
>> -        /* OUT: SID list */
>> -        XEN_GUEST_HANDLE(uint32) sids;
>> -    } u;
>> -};
>
> No known users or not, we don't normally allow breaking code that
> may be consuming any of our public headers. I.e. conventionally,
> for interfaces not restricted to the tool stack we keep everything,
> but guard it with a __XEN_INTERFACE_VERSION__ conditional.
>
> Whether making an exception here is okay I'm not certain; in any
> event would you imo need to bump XEN_FLASK_INTERFACE_VERSION.
>
> Jan

OK, then I'll drop this patch.

-- 
Daniel De Graaf
National Security Agency

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

Re: [PATCH 10/15] flask: remove xen_flask_userlist operation

[Jan Beulich]

>>> On 09.06.16 at 18:43, <dgdegra@tycho.nsa.gov> wrote:
> On 06/09/2016 12:07 PM, Jan Beulich wrote:
>>>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
>>> --- a/xen/include/public/xsm/flask_op.h
>>> +++ b/xen/include/public/xsm/flask_op.h
>>> @@ -70,20 +70,6 @@ struct xen_flask_transition {
>>>      uint32_t newsid;
>>>  };
>>>
>>> -struct xen_flask_userlist {
>>> -    /* IN: starting SID for list */
>>> -    uint32_t start_sid;
>>> -    /* IN: size of user string and output buffer
>>> -     * OUT: number of SIDs returned */
>>> -    uint32_t size;
>>> -    union {
>>> -        /* IN: user to enumerate SIDs */
>>> -        XEN_GUEST_HANDLE(char) user;
>>> -        /* OUT: SID list */
>>> -        XEN_GUEST_HANDLE(uint32) sids;
>>> -    } u;
>>> -};
>>
>> No known users or not, we don't normally allow breaking code that
>> may be consuming any of our public headers. I.e. conventionally,
>> for interfaces not restricted to the tool stack we keep everything,
>> but guard it with a __XEN_INTERFACE_VERSION__ conditional.
>>
>> Whether making an exception here is okay I'm not certain; in any
>> event would you imo need to bump XEN_FLASK_INTERFACE_VERSION.
> 
> OK, then I'll drop this patch.

Well, no, please don't drop it, make it add aforementioned #if-s.
(And after thinking about it again, bumping the interface version
doesn't seem to make sense for a plain removal.)

Jan


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

Re: [PATCH 10/15] flask: remove xen_flask_userlist operation

[Daniel De Graaf]

On 06/10/2016 02:51 AM, Jan Beulich wrote:
>>>> On 09.06.16 at 18:43, <dgdegra@tycho.nsa.gov> wrote:
>> On 06/09/2016 12:07 PM, Jan Beulich wrote:
>>>>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
>>>> --- a/xen/include/public/xsm/flask_op.h
>>>> +++ b/xen/include/public/xsm/flask_op.h
>>>> @@ -70,20 +70,6 @@ struct xen_flask_transition {
>>>>      uint32_t newsid;
>>>>  };
>>>>
>>>> -struct xen_flask_userlist {
>>>> -    /* IN: starting SID for list */
>>>> -    uint32_t start_sid;
>>>> -    /* IN: size of user string and output buffer
>>>> -     * OUT: number of SIDs returned */
>>>> -    uint32_t size;
>>>> -    union {
>>>> -        /* IN: user to enumerate SIDs */
>>>> -        XEN_GUEST_HANDLE(char) user;
>>>> -        /* OUT: SID list */
>>>> -        XEN_GUEST_HANDLE(uint32) sids;
>>>> -    } u;
>>>> -};
>>>
>>> No known users or not, we don't normally allow breaking code that
>>> may be consuming any of our public headers. I.e. conventionally,
>>> for interfaces not restricted to the tool stack we keep everything,
>>> but guard it with a __XEN_INTERFACE_VERSION__ conditional.
>>>
>>> Whether making an exception here is okay I'm not certain; in any
>>> event would you imo need to bump XEN_FLASK_INTERFACE_VERSION.
>>
>> OK, then I'll drop this patch.
>
> Well, no, please don't drop it, make it add aforementioned #if-s.
> (And after thinking about it again, bumping the interface version
> doesn't seem to make sense for a plain removal.)

Ah, I misunderstood your comment - I read the conditional as belonging
to the code instead of the header, which makes a lot more sense.

Does the value of __XEN_LATEST_INTERFACE_VERSION__ need to be bumped to
0x00040800 after the branching process?

-- 
Daniel De Graaf
National Security Agency

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

Re: [PATCH 10/15] flask: remove xen_flask_userlist operation

[Jan Beulich]

>>> On 10.06.16 at 15:08, <dgdegra@tycho.nsa.gov> wrote:
> On 06/10/2016 02:51 AM, Jan Beulich wrote:
>>>>> On 09.06.16 at 18:43, <dgdegra@tycho.nsa.gov> wrote:
>>> On 06/09/2016 12:07 PM, Jan Beulich wrote:
>>>>>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
>>>>> --- a/xen/include/public/xsm/flask_op.h
>>>>> +++ b/xen/include/public/xsm/flask_op.h
>>>>> @@ -70,20 +70,6 @@ struct xen_flask_transition {
>>>>>      uint32_t newsid;
>>>>>  };
>>>>>
>>>>> -struct xen_flask_userlist {
>>>>> -    /* IN: starting SID for list */
>>>>> -    uint32_t start_sid;
>>>>> -    /* IN: size of user string and output buffer
>>>>> -     * OUT: number of SIDs returned */
>>>>> -    uint32_t size;
>>>>> -    union {
>>>>> -        /* IN: user to enumerate SIDs */
>>>>> -        XEN_GUEST_HANDLE(char) user;
>>>>> -        /* OUT: SID list */
>>>>> -        XEN_GUEST_HANDLE(uint32) sids;
>>>>> -    } u;
>>>>> -};
>>>>
>>>> No known users or not, we don't normally allow breaking code that
>>>> may be consuming any of our public headers. I.e. conventionally,
>>>> for interfaces not restricted to the tool stack we keep everything,
>>>> but guard it with a __XEN_INTERFACE_VERSION__ conditional.
>>>>
>>>> Whether making an exception here is okay I'm not certain; in any
>>>> event would you imo need to bump XEN_FLASK_INTERFACE_VERSION.
>>>
>>> OK, then I'll drop this patch.
>>
>> Well, no, please don't drop it, make it add aforementioned #if-s.
>> (And after thinking about it again, bumping the interface version
>> doesn't seem to make sense for a plain removal.)
> 
> Ah, I misunderstood your comment - I read the conditional as belonging
> to the code instead of the header, which makes a lot more sense.
> 
> Does the value of __XEN_LATEST_INTERFACE_VERSION__ need to be bumped to
> 0x00040800 after the branching process?

Whenever that's first needed. One of the patches I have in the
works does so, but if yours lands earlier it should do the update.

Jan


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

[PATCH 11/15] flask: improve unknown permission handling

[Daniel De Graaf]

When an unknown domctl, sysctl, or other operation is encountered in the
FLASK security server, use the allow_unknown bit in the security policy
to decide if the permission should be allowed or denied.  This bit is
off by default, but it can be set by using checkpolicy -U allow when
compiling the policy.  This allows new operations to be tested without
needing to immediately add security checks; however, it is not flexible
enough to avoid adding the actual permission checks.  An error message
is printed to the hypervisor console when this fallback is encountered.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c            | 44 +++++++++++++++++++++++++---------------
 xen/xsm/flask/include/security.h |  2 ++
 xen/xsm/flask/ss/policydb.c      |  1 +
 xen/xsm/flask/ss/policydb.h      |  6 ++++++
 xen/xsm/flask/ss/services.c      |  5 +++++
 5 files changed, 42 insertions(+), 16 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a8d45e7..3ab3fbf 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -136,6 +136,23 @@ static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
     return 0;
 }
 
+static int avc_unknown_permission(const char *name, int id)
+{
+    int rc;
+    if ( !flask_enforcing || security_get_allow_unknown() )
+    {
+        printk(XENLOG_G_WARNING "FLASK: Allowing unknown %s: %d.\n", name, id);
+        rc = 0;
+    }
+    else
+    {
+        printk(XENLOG_G_ERR "FLASK: Denying unknown %s: %d.\n", name, id);
+        rc = -EPERM;
+    }
+
+    return rc;
+}
+
 static int flask_domain_alloc_security(struct domain *d)
 {
     struct domain_security_struct *dsec;
@@ -271,7 +288,7 @@ static int flask_evtchn_send(struct domain *d, struct evtchn *chn)
         rc = 0;
         break;
     default:
-        rc = -EPERM;
+        rc = avc_unknown_permission("event channel state", chn->state);
     }
 
     return rc;
@@ -423,7 +440,7 @@ static int flask_console_io(struct domain *d, int cmd)
         perm = XEN__WRITECONSOLE;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("console_io", cmd);
     }
 
     return domain_has_xen(d, perm);
@@ -455,7 +472,7 @@ static int flask_profile(struct domain *d, int op)
         perm = XEN__PRIVPROFILE;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("xenoprof op", op);
     }
 
     return domain_has_xen(d, perm);
@@ -521,8 +538,7 @@ static int flask_domctl_scheduler_op(struct domain *d, int op)
         return current_has_perm(d, SECCLASS_DOMAIN, DOMAIN__GETSCHEDULER);
 
     default:
-        printk("flask_domctl_scheduler_op: Unknown op %d\n", op);
-        return -EPERM;
+        return avc_unknown_permission("domctl_scheduler_op", op);
     }
 }
 
@@ -537,8 +553,7 @@ static int flask_sysctl_scheduler_op(int op)
         return domain_has_xen(current->domain, XEN__GETSCHEDULER);
 
     default:
-        printk("flask_sysctl_scheduler_op: Unknown op %d\n", op);
-        return -EPERM;
+        return avc_unknown_permission("sysctl_scheduler_op", op);
     }
 }
 
@@ -735,8 +750,7 @@ static int flask_domctl(struct domain *d, int cmd)
         return current_has_perm(d, SECCLASS_DOMAIN2, DOMAIN2__SOFT_RESET);
 
     default:
-        printk("flask_domctl: Unknown op %d\n", cmd);
-        return -EPERM;
+        return avc_unknown_permission("domctl", cmd);
     }
 }
 
@@ -811,8 +825,7 @@ static int flask_sysctl(int cmd)
                                     XEN2__LIVEPATCH_OP, NULL);
 
     default:
-        printk("flask_sysctl: Unknown op %d\n", cmd);
-        return -EPERM;
+        return avc_unknown_permission("sysctl", cmd);
     }
 }
 
@@ -1129,7 +1142,7 @@ static inline int flask_page_offline(uint32_t cmd)
     case sysctl_query_page_offline:
         return flask_resource_use_core();
     default:
-        return -EPERM;
+        return avc_unknown_permission("page_offline", cmd);
     }
 }
 
@@ -1402,8 +1415,7 @@ static int flask_platform_op(uint32_t op)
                             SECCLASS_XEN2, XEN2__GET_SYMBOL, NULL);
 
     default:
-        printk("flask_platform_op: Unknown op %d\n", op);
-        return -EPERM;
+        return avc_unknown_permission("platform_op", op);
     }
 }
 
@@ -1434,7 +1446,7 @@ static int flask_shadow_control(struct domain *d, uint32_t op)
         perm = SHADOW__LOGDIRTY;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("shadow_control", op);
     }
 
     return current_has_perm(d, SECCLASS_SHADOW, perm);
@@ -1538,7 +1550,7 @@ static int flask_apic(struct domain *d, int cmd)
         perm = XEN__WRITEAPIC;
         break;
     default:
-        return -EPERM;
+        return avc_unknown_permission("apic", cmd);
     }
 
     return domain_has_xen(d, perm);
diff --git a/xen/xsm/flask/include/security.h b/xen/xsm/flask/include/security.h
index 2b00177..1da020d 100644
--- a/xen/xsm/flask/include/security.h
+++ b/xen/xsm/flask/include/security.h
@@ -78,6 +78,8 @@ int security_sid_to_context(u32 sid, char **scontext, u32 *scontext_len);
 
 int security_context_to_sid(char *scontext, u32 scontext_len, u32 *out_sid);
 
+int security_get_allow_unknown(void);
+
 int security_irq_sid(int pirq, u32 *out_sid);
 
 int security_iomem_sid(unsigned long, u32 *out_sid);
diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index 8aa88c1..46574c3 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -1843,6 +1843,7 @@ int policydb_read(struct policydb *p, void *fp)
             goto bad;
         }
     }
+    p->allow_unknown = !!(le32_to_cpu(buf[1]) & ALLOW_UNKNOWN);
 
     if ( p->policyvers >= POLICYDB_VERSION_POLCAP &&
          ebitmap_read(&p->policycaps, fp) != 0 )
diff --git a/xen/xsm/flask/ss/policydb.h b/xen/xsm/flask/ss/policydb.h
index 50e22f3..eb1e44d 100644
--- a/xen/xsm/flask/ss/policydb.h
+++ b/xen/xsm/flask/ss/policydb.h
@@ -246,6 +246,8 @@ struct policydb {
 
     unsigned int policyvers;
 
+    unsigned int allow_unknown : 1;
+
     u16 target_type;
 };
 
@@ -261,6 +263,10 @@ extern int policydb_read(struct policydb *p, void *fp);
 
 #define POLICYDB_CONFIG_MLS    1
 
+/* the config flags related to unknown classes/perms are bits 2 and 3 */
+#define REJECT_UNKNOWN 0x00000002
+#define ALLOW_UNKNOWN  0x00000004
+
 #define OBJECT_R "object_r"
 #define OBJECT_R_VAL 1
 
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index c9b27a0..ce880e9 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1465,6 +1465,11 @@ err:
 
 }
 
+int security_get_allow_unknown(void)
+{
+    return policydb.allow_unknown;
+}
+
 /**
  * security_irq_sid - Obtain the SID for a physical irq.
  * @pirq: physical irq
-- 
2.5.5


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

Re: [PATCH 11/15] flask: improve unknown permission handling

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:14AM -0400, Daniel De Graaf wrote:
> When an unknown domctl, sysctl, or other operation is encountered in the
> FLASK security server, use the allow_unknown bit in the security policy
> to decide if the permission should be allowed or denied.  This bit is
> off by default, but it can be set by using checkpolicy -U allow when
> compiling the policy.  This allows new operations to be tested without
> needing to immediately add security checks; however, it is not flexible
> enough to avoid adding the actual permission checks.  An error message
> is printed to the hypervisor console when this fallback is encountered.

.. and the operation is permitted.

> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  xen/xsm/flask/hooks.c            | 44 +++++++++++++++++++++++++---------------
>  xen/xsm/flask/include/security.h |  2 ++
>  xen/xsm/flask/ss/policydb.c      |  1 +
>  xen/xsm/flask/ss/policydb.h      |  6 ++++++
>  xen/xsm/flask/ss/services.c      |  5 +++++
>  5 files changed, 42 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index a8d45e7..3ab3fbf 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -136,6 +136,23 @@ static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
>      return 0;
>  }
>  
> +static int avc_unknown_permission(const char *name, int id)
> +{
> +    int rc;

I would add a new line here.
> +    if ( !flask_enforcing || security_get_allow_unknown() )
> +    {
> +        printk(XENLOG_G_WARNING "FLASK: Allowing unknown %s: %d.\n", name, id);
> +        rc = 0;
> +    }
> +    else
> +    {
> +        printk(XENLOG_G_ERR "FLASK: Denying unknown %s: %d.\n", name, id);
> +        rc = -EPERM;
> +    }
> +
> +    return rc;
> +}
> +

The rest looks OK, but I have a question: Is this how Linux operates?


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

Re: [PATCH 11/15] flask: improve unknown permission handling

[Daniel De Graaf]

On 06/17/2016 11:45 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 09, 2016 at 10:47:14AM -0400, Daniel De Graaf wrote:
>> When an unknown domctl, sysctl, or other operation is encountered in the
>> FLASK security server, use the allow_unknown bit in the security policy
>> to decide if the permission should be allowed or denied.  This bit is
>> off by default, but it can be set by using checkpolicy -U allow when
>> compiling the policy.  This allows new operations to be tested without
>> needing to immediately add security checks; however, it is not flexible
>> enough to avoid adding the actual permission checks.  An error message
>> is printed to the hypervisor console when this fallback is encountered.
>
> .. and the operation is permitted.

The error message is printed either way (with a different priority).  Were
you suggesting I expand this explanation to include both the error and
warning messages separately?

>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  xen/xsm/flask/hooks.c            | 44 +++++++++++++++++++++++++---------------
>>  xen/xsm/flask/include/security.h |  2 ++
>>  xen/xsm/flask/ss/policydb.c      |  1 +
>>  xen/xsm/flask/ss/policydb.h      |  6 ++++++
>>  xen/xsm/flask/ss/services.c      |  5 +++++
>>  5 files changed, 42 insertions(+), 16 deletions(-)
>>
>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>> index a8d45e7..3ab3fbf 100644
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -136,6 +136,23 @@ static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
>>      return 0;
>>  }
>>
>> +static int avc_unknown_permission(const char *name, int id)
>> +{
>> +    int rc;
>
> I would add a new line here.

OK

>> +    if ( !flask_enforcing || security_get_allow_unknown() )
>> +    {
>> +        printk(XENLOG_G_WARNING "FLASK: Allowing unknown %s: %d.\n", name, id);
>> +        rc = 0;
>> +    }
>> +    else
>> +    {
>> +        printk(XENLOG_G_ERR "FLASK: Denying unknown %s: %d.\n", name, id);
>> +        rc = -EPERM;
>> +    }
>> +
>> +    return rc;
>> +}
>> +
>
> The rest looks OK, but I have a question: Is this how Linux operates?

Yes; selinux_nlmsg_perm for an unknown netlink message seems to be an
example there.

-- 
Daniel De Graaf
National Security Agency

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

Re: [PATCH 11/15] flask: improve unknown permission handling

[Konrad Rzeszutek Wilk]

On Fri, Jun 17, 2016 at 01:02:58PM -0400, Daniel De Graaf wrote:
> On 06/17/2016 11:45 AM, Konrad Rzeszutek Wilk wrote:
> >On Thu, Jun 09, 2016 at 10:47:14AM -0400, Daniel De Graaf wrote:
> >>When an unknown domctl, sysctl, or other operation is encountered in the
> >>FLASK security server, use the allow_unknown bit in the security policy
> >>to decide if the permission should be allowed or denied.  This bit is
> >>off by default, but it can be set by using checkpolicy -U allow when
> >>compiling the policy.  This allows new operations to be tested without
> >>needing to immediately add security checks; however, it is not flexible
> >>enough to avoid adding the actual permission checks.  An error message
> >>is printed to the hypervisor console when this fallback is encountered.
> >
> >.. and the operation is permitted.
> 
> The error message is printed either way (with a different priority).  Were

correct.
> you suggesting I expand this explanation to include both the error and
> warning messages separately?

It just that the patch changes the behavior. That is in the past if
you had created an policy using checkpolicy -U allow it would print an
error and return -EPERM.

But now it will print an error and return 0 and pass the XSM check 
(aka operation ends being permitted).

> 
> >>
> >>Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >>---
> >> xen/xsm/flask/hooks.c            | 44 +++++++++++++++++++++++++---------------
> >> xen/xsm/flask/include/security.h |  2 ++
> >> xen/xsm/flask/ss/policydb.c      |  1 +
> >> xen/xsm/flask/ss/policydb.h      |  6 ++++++
> >> xen/xsm/flask/ss/services.c      |  5 +++++
> >> 5 files changed, 42 insertions(+), 16 deletions(-)
> >>
> >>diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> >>index a8d45e7..3ab3fbf 100644
> >>--- a/xen/xsm/flask/hooks.c
> >>+++ b/xen/xsm/flask/hooks.c
> >>@@ -136,6 +136,23 @@ static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
> >>     return 0;
> >> }
> >>
> >>+static int avc_unknown_permission(const char *name, int id)
> >>+{
> >>+    int rc;
> >
> >I would add a new line here.
> 
> OK
> 
> >>+    if ( !flask_enforcing || security_get_allow_unknown() )
> >>+    {
> >>+        printk(XENLOG_G_WARNING "FLASK: Allowing unknown %s: %d.\n", name, id);
> >>+        rc = 0;
> >>+    }
> >>+    else
> >>+    {
> >>+        printk(XENLOG_G_ERR "FLASK: Denying unknown %s: %d.\n", name, id);
> >>+        rc = -EPERM;
> >>+    }
> >>+
> >>+    return rc;
> >>+}
> >>+
> >
> >The rest looks OK, but I have a question: Is this how Linux operates?
> 
> Yes; selinux_nlmsg_perm for an unknown netlink message seems to be an
> example there.
> 
> -- 
> Daniel De Graaf
> National Security Agency

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

Re: [PATCH 11/15] flask: improve unknown permission handling

[Daniel De Graaf]

On 06/17/2016 01:13 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 17, 2016 at 01:02:58PM -0400, Daniel De Graaf wrote:
>> On 06/17/2016 11:45 AM, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Jun 09, 2016 at 10:47:14AM -0400, Daniel De Graaf wrote:
>>>> When an unknown domctl, sysctl, or other operation is encountered in the
>>>> FLASK security server, use the allow_unknown bit in the security policy
>>>> to decide if the permission should be allowed or denied.  This bit is
>>>> off by default, but it can be set by using checkpolicy -U allow when
>>>> compiling the policy.  This allows new operations to be tested without
>>>> needing to immediately add security checks; however, it is not flexible
>>>> enough to avoid adding the actual permission checks.  An error message
>>>> is printed to the hypervisor console when this fallback is encountered.
>>>
>>> .. and the operation is permitted.
>>
>> The error message is printed either way (with a different priority).  Were
>
> correct.
>> you suggesting I expand this explanation to include both the error and
>> warning messages separately?
>
> It just that the patch changes the behavior. That is in the past if
> you had created an policy using checkpolicy -U allow it would print an
> error and return -EPERM.
>
> But now it will print an error and return 0 and pass the XSM check
> (aka operation ends being permitted).

I would be surprised if someone actually used allow_unknown before now,
since it did nothing and required manually enabling.  But if they did,
this is a functionality change.  I'll add a note of that.

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

[PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Daniel De Graaf]

Since FLASK is the only implementation of XSM hooks in Xen, using an
iterated initcall dispatch for setup is overly complex.  Change this to
a direct function call to a globally visible function; if additional XSM
hooks are added in the future, a switching mechanism will be needed
regardless, and that can be placed in xsm_core.c.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/arm/xen.lds.S |  5 -----
 xen/arch/x86/xen.lds.S |  5 -----
 xen/common/Kconfig     | 37 +++++++++++++++++++------------------
 xen/include/xsm/xsm.h  | 16 ++++++++--------
 xen/xsm/flask/hooks.c  |  4 +---
 xen/xsm/xsm_core.c     |  8 +-------
 6 files changed, 29 insertions(+), 46 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 76982b2..8320381 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -162,11 +162,6 @@ SECTIONS
        *(.initcall1.init)
        __initcall_end = .;
   } :text
-  .xsm_initcall.init : {
-       __xsm_initcall_start = .;
-       *(.xsm_initcall.init)
-       __xsm_initcall_end = .;
-  } :text
   __init_end_efi = .;
   . = ALIGN(STACK_SIZE);
   __init_end = .;
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index a43b29d..dcbb8fe 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -190,11 +190,6 @@ SECTIONS
        *(.initcall1.init)
        __initcall_end = .;
   } :text
-  .xsm_initcall.init : {
-       __xsm_initcall_start = .;
-       *(.xsm_initcall.init)
-       __xsm_initcall_end = .;
-  } :text
   . = ALIGN(PAGE_SIZE);
   __init_end = .;
 
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index cd59574..b8f1800 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -11,24 +11,6 @@ config COMPAT
 config CORE_PARKING
 	bool
 
-config FLASK
-	bool "FLux Advanced Security Kernel support"
-	default y
-	depends on XSM
-	---help---
-	  Enables the FLASK (FLux Advanced Security Kernel) support which
-	  provides a mandatory access control framework by which security
-	  enforcement, isolation, and auditing can be achieved with fine
-	  granular control via a security policy.
-
-	  If unsure, say N.
-
-config FLASK_AVC_STATS
-	def_bool y
-	depends on FLASK
-	---help---
-	  Maintain statistics on the access vector cache
-
 # Select HAS_DEVICE_TREE if device tree is supported
 config HAS_DEVICE_TREE
 	bool
@@ -137,6 +119,25 @@ config XSM
 
 	  If unsure, say N.
 
+config FLASK
+	bool "FLux Advanced Security Kernel support"
+	default y
+	depends on XSM
+	---help---
+	  Enables FLASK (FLux Advanced Security Kernel) as the access control
+	  mechanism used by the XSM framework.  This provides a mandatory access
+	  control framework by which security enforcement, isolation, and
+	  auditing can be achieved with fine granular control via a security
+	  policy.
+
+	  If unsure, say Y.
+
+config FLASK_AVC_STATS
+	def_bool y
+	depends on FLASK
+	---help---
+	  Maintain statistics on the access vector cache
+
 # Enable schedulers
 menu "Schedulers"
 	visible if EXPERT = "y"
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 8ed8ee5..0d525ec 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -46,14 +46,6 @@ typedef enum xsm_default xsm_default_t;
 extern char *policy_buffer;
 extern u32 policy_size;
 
-typedef void (*xsm_initcall_t)(void);
-
-extern xsm_initcall_t __xsm_initcall_start[], __xsm_initcall_end[];
-
-#define xsm_initcall(fn) \
-    static xsm_initcall_t __initcall_##fn \
-    __used_section(".xsm_initcall.init") = fn
-
 struct xsm_operations {
     void (*security_domaininfo) (struct domain *d,
                                         struct xen_domctl_getdomaininfo *info);
@@ -763,6 +755,14 @@ extern int unregister_xsm(struct xsm_operations *ops);
 extern struct xsm_operations dummy_xsm_ops;
 extern void xsm_fixup_ops(struct xsm_operations *ops);
 
+#ifdef CONFIG_FLASK
+extern void flask_init(void);
+#else
+static inline void flask_init(void)
+{
+}
+#endif
+
 #else /* CONFIG_XSM */
 
 #include <xsm/dummy.h>
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 3ab3fbf..596ac0a 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1816,7 +1816,7 @@ static struct xsm_operations flask_ops = {
     .xen_version = flask_xen_version,
 };
 
-static __init void flask_init(void)
+__init void flask_init(void)
 {
     int ret = -ENOENT;
 
@@ -1859,8 +1859,6 @@ static __init void flask_init(void)
         printk(XENLOG_INFO "Flask:  Starting in permissive mode.\n");
 }
 
-xsm_initcall(flask_init);
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 634ec98..cb2fdb6 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -38,13 +38,7 @@ static inline int verify(struct xsm_operations *ops)
 
 static void __init do_xsm_initcalls(void)
 {
-    xsm_initcall_t *call;
-    call = __xsm_initcall_start;
-    while ( call < __xsm_initcall_end )
-    {
-        (*call) ();
-        call++;
-    }
+    flask_init();
 }
 
 static int __init xsm_core_init(void)
-- 
2.5.5


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

Re: [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Andrew Cooper]

On 09/06/16 15:47, Daniel De Graaf wrote:
> Since FLASK is the only implementation of XSM hooks in Xen, using an
> iterated initcall dispatch for setup is overly complex.  Change this to
> a direct function call to a globally visible function; if additional XSM
> hooks are added in the future, a switching mechanism will be needed
> regardless, and that can be placed in xsm_core.c.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks for fixing the menuconfig bug; I was about to submit a fix
myself.  This is one case where ordering things alphabetically in the
file not the highest priority.

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

Re: [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Jan Beulich]

>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
> Since FLASK is the only implementation of XSM hooks in Xen, using an
> iterated initcall dispatch for setup is overly complex.  Change this to
> a direct function call to a globally visible function; if additional XSM
> hooks are added in the future, a switching mechanism will be needed
> regardless, and that can be placed in xsm_core.c.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

While I agree with the Kconfig change, it not being mentioned at
all in the description is confusing. Does it need to be part of this
patch? Or can it rather be a separate one with a proper description?

Jan


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

Re: [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Daniel De Graaf]

On 06/09/2016 12:11 PM, Jan Beulich wrote:
>>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
>> Since FLASK is the only implementation of XSM hooks in Xen, using an
>> iterated initcall dispatch for setup is overly complex.  Change this to
>> a direct function call to a globally visible function; if additional XSM
>> hooks are added in the future, a switching mechanism will be needed
>> regardless, and that can be placed in xsm_core.c.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>
> While I agree with the Kconfig change, it not being mentioned at
> all in the description is confusing. Does it need to be part of this
> patch? Or can it rather be a separate one with a proper description?
>
> Jan

It does not need to be part of this patch; it just ended up here because
the other Kconfig changes that I made were not useful and got dropped.

-- 
Daniel De Graaf
National Security Agency

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

Re: [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:15AM -0400, Daniel De Graaf wrote:
> Since FLASK is the only implementation of XSM hooks in Xen, using an
> iterated initcall dispatch for setup is overly complex.  Change this to

As such, should the Kconfig file enable the FLASK by default?
Or make the XSM entry have the configuration for FLASK?

Or perhaps make the FLASK be the visible one and select XSM?

> a direct function call to a globally visible function; if additional XSM
> hooks are added in the future, a switching mechanism will be needed
> regardless, and that can be placed in xsm_core.c.

> +config FLASK
> +	bool "FLux Advanced Security Kernel support"
> +	default y
> +	depends on XSM

So this would be 'select XSM' ?
> +	---help---
> +	  Enables FLASK (FLux Advanced Security Kernel) as the access control
> +	  mechanism used by the XSM framework.  This provides a mandatory access
> +	  control framework by which security enforcement, isolation, and
> +	  auditing can be achieved with fine granular control via a security
> +	  policy.
> +
> +	  If unsure, say Y.
> +
> +config FLASK_AVC_STATS
> +	def_bool y
> +	depends on FLASK
> +	---help---
> +	  Maintain statistics on the access vector cache
> +
>  # Enable schedulers
>  menu "Schedulers"
>  	visible if EXPERT = "y"
> diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
> index 634ec98..cb2fdb6 100644
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -38,13 +38,7 @@ static inline int verify(struct xsm_operations *ops)
>  
>  static void __init do_xsm_initcalls(void)
>  {
> -    xsm_initcall_t *call;
> -    call = __xsm_initcall_start;
> -    while ( call < __xsm_initcall_end )
> -    {
> -        (*call) ();
> -        call++;
> -    }
> +    flask_init();

Could you delete do_xsm_initcalls() and make xsm_init() call flask_init() ?

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

Re: [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Daniel De Graaf]

On 06/17/2016 11:50 AM, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 09, 2016 at 10:47:15AM -0400, Daniel De Graaf wrote:
>> Since FLASK is the only implementation of XSM hooks in Xen, using an
>> iterated initcall dispatch for setup is overly complex.  Change this to
>
> As such, should the Kconfig file enable the FLASK by default?
> Or make the XSM entry have the configuration for FLASK?
>
> Or perhaps make the FLASK be the visible one and select XSM?

XSM has previously been the configuration option to enable.  If XSM is
enabled (by choice), FLASK will then be enabled by default.

Logically, FLASK is an implementation of XSM, and while it would be
possible to swap them, this would probably need to be done by hiding the
XSM option from the user.

>> a direct function call to a globally visible function; if additional XSM
>> hooks are added in the future, a switching mechanism will be needed
>> regardless, and that can be placed in xsm_core.c.
>
>> +config FLASK
>> +	bool "FLux Advanced Security Kernel support"
>> +	default y
>> +	depends on XSM
>
> So this would be 'select XSM' ?
>> +	---help---
>> +	  Enables FLASK (FLux Advanced Security Kernel) as the access control
>> +	  mechanism used by the XSM framework.  This provides a mandatory access
>> +	  control framework by which security enforcement, isolation, and
>> +	  auditing can be achieved with fine granular control via a security
>> +	  policy.
>> +
>> +	  If unsure, say Y.
>> +
>> +config FLASK_AVC_STATS
>> +	def_bool y
>> +	depends on FLASK
>> +	---help---
>> +	  Maintain statistics on the access vector cache
>> +
>>  # Enable schedulers
>>  menu "Schedulers"
>>  	visible if EXPERT = "y"
>> diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
>> index 634ec98..cb2fdb6 100644
>> --- a/xen/xsm/xsm_core.c
>> +++ b/xen/xsm/xsm_core.c
>> @@ -38,13 +38,7 @@ static inline int verify(struct xsm_operations *ops)
>>
>>  static void __init do_xsm_initcalls(void)
>>  {
>> -    xsm_initcall_t *call;
>> -    call = __xsm_initcall_start;
>> -    while ( call < __xsm_initcall_end )
>> -    {
>> -        (*call) ();
>> -        call++;
>> -    }
>> +    flask_init();
>
> Could you delete do_xsm_initcalls() and make xsm_init() call flask_init() ?

Sure.

-- 
Daniel De Graaf
National Security Agency

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

Re: [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Konrad Rzeszutek Wilk]

On Fri, Jun 17, 2016 at 01:04:01PM -0400, Daniel De Graaf wrote:
> On 06/17/2016 11:50 AM, Konrad Rzeszutek Wilk wrote:
> >On Thu, Jun 09, 2016 at 10:47:15AM -0400, Daniel De Graaf wrote:
> >>Since FLASK is the only implementation of XSM hooks in Xen, using an
> >>iterated initcall dispatch for setup is overly complex.  Change this to
> >
> >As such, should the Kconfig file enable the FLASK by default?
> >Or make the XSM entry have the configuration for FLASK?
> >
> >Or perhaps make the FLASK be the visible one and select XSM?
> 
> XSM has previously been the configuration option to enable.  If XSM is
> enabled (by choice), FLASK will then be enabled by default.

Ah, OK. I need to check, but could you disable FLASK and still have XSM enabled?

> 
> Logically, FLASK is an implementation of XSM, and while it would be
> possible to swap them, this would probably need to be done by hiding the
> XSM option from the user.

Right.

> 
> >>a direct function call to a globally visible function; if additional XSM
> >>hooks are added in the future, a switching mechanism will be needed
> >>regardless, and that can be placed in xsm_core.c.
> >

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

Re: [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Daniel De Graaf]

On 06/17/2016 01:14 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 17, 2016 at 01:04:01PM -0400, Daniel De Graaf wrote:
>> On 06/17/2016 11:50 AM, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Jun 09, 2016 at 10:47:15AM -0400, Daniel De Graaf wrote:
>>>> Since FLASK is the only implementation of XSM hooks in Xen, using an
>>>> iterated initcall dispatch for setup is overly complex.  Change this to
>>>
>>> As such, should the Kconfig file enable the FLASK by default?
>>> Or make the XSM entry have the configuration for FLASK?
>>>
>>> Or perhaps make the FLASK be the visible one and select XSM?
>>
>> XSM has previously been the configuration option to enable.  If XSM is
>> enabled (by choice), FLASK will then be enabled by default.
>
> Ah, OK. I need to check, but could you disable FLASK and still have XSM enabled?

Yes, but it won't do anything except slow down the hypervisor a bit.
It's the same behavior as enabling flask and passing "flask=disabled" on
the hypervisor command line.

If someone wanted to write another XSM implementation (or resurrect the
old ACM module), this would be the starting point for that.


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

Re: [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Konrad Rzeszutek Wilk]

On Fri, Jun 17, 2016 at 01:18:47PM -0400, Daniel De Graaf wrote:
> On 06/17/2016 01:14 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Jun 17, 2016 at 01:04:01PM -0400, Daniel De Graaf wrote:
> >>On 06/17/2016 11:50 AM, Konrad Rzeszutek Wilk wrote:
> >>>On Thu, Jun 09, 2016 at 10:47:15AM -0400, Daniel De Graaf wrote:
> >>>>Since FLASK is the only implementation of XSM hooks in Xen, using an
> >>>>iterated initcall dispatch for setup is overly complex.  Change this to
> >>>
> >>>As such, should the Kconfig file enable the FLASK by default?
> >>>Or make the XSM entry have the configuration for FLASK?
> >>>
> >>>Or perhaps make the FLASK be the visible one and select XSM?
> >>
> >>XSM has previously been the configuration option to enable.  If XSM is
> >>enabled (by choice), FLASK will then be enabled by default.
> >
> >Ah, OK. I need to check, but could you disable FLASK and still have XSM enabled?
> 
> Yes, but it won't do anything except slow down the hypervisor a bit.
> It's the same behavior as enabling flask and passing "flask=disabled" on
> the hypervisor command line.

Right. Would it make sense to squash XSM and FLASK together in the Kconfig?

> 
> If someone wanted to write another XSM implementation (or resurrect the
> old ACM module), this would be the starting point for that.
> 

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

Re: [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section

[Daniel De Graaf]

On 06/17/2016 01:21 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 17, 2016 at 01:18:47PM -0400, Daniel De Graaf wrote:
>> On 06/17/2016 01:14 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Jun 17, 2016 at 01:04:01PM -0400, Daniel De Graaf wrote:
>>>> On 06/17/2016 11:50 AM, Konrad Rzeszutek Wilk wrote:
>>>>> On Thu, Jun 09, 2016 at 10:47:15AM -0400, Daniel De Graaf wrote:
>>>>>> Since FLASK is the only implementation of XSM hooks in Xen, using an
>>>>>> iterated initcall dispatch for setup is overly complex.  Change this to
>>>>>
>>>>> As such, should the Kconfig file enable the FLASK by default?
>>>>> Or make the XSM entry have the configuration for FLASK?
>>>>>
>>>>> Or perhaps make the FLASK be the visible one and select XSM?
>>>>
>>>> XSM has previously been the configuration option to enable.  If XSM is
>>>> enabled (by choice), FLASK will then be enabled by default.
>>>
>>> Ah, OK. I need to check, but could you disable FLASK and still have XSM enabled?
>>
>> Yes, but it won't do anything except slow down the hypervisor a bit.
>> It's the same behavior as enabling flask and passing "flask=disabled" on
>> the hypervisor command line.
>
> Right. Would it make sense to squash XSM and FLASK together in the Kconfig?

When making the Kconifg changes, I originally tried making a choice option for
the XSM provider (like for scheduler), with FLASK and dummy being the two
choices.  I discarded that because it didn't add anything useful over the
binary option.

However, thinking about it, if it doesn't make sense to disable FLASK then
hiding the option would simplify the configuration. It removes the grouping of
flask-only options, but since there's only one that isn't all that important.



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

[PATCH 13/15] xsm: annotate setup functions with __init

[Daniel De Graaf]

These functions were only called from __init functions.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/dummy.c    | 2 +-
 xen/xsm/xsm_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 9791ad4..a082b28 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -27,7 +27,7 @@ struct xsm_operations dummy_xsm_ops;
         }                                                              \
     } while (0)
 
-void xsm_fixup_ops (struct xsm_operations *ops)
+void __init xsm_fixup_ops (struct xsm_operations *ops)
 {
     set_to_dummy_if_null(ops, security_domaininfo);
     set_to_dummy_if_null(ops, domain_create);
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index cb2fdb6..2c4d576 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -132,7 +132,7 @@ bool __init has_xsm_magic(paddr_t start)
 }
 #endif
 
-int register_xsm(struct xsm_operations *ops)
+int __init register_xsm(struct xsm_operations *ops)
 {
     if ( verify(ops) )
     {
-- 
2.5.5


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

Re: [PATCH 13/15] xsm: annotate setup functions with __init

[Andrew Cooper]

On 09/06/16 15:47, Daniel De Graaf wrote:
> These functions were only called from __init functions.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

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

[PATCH 14/15] xsm: clean up unregistration

[Daniel De Graaf]

The only possible value of original_ops was &dummy_xsm_ops, and
unregister_xsm was never used.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/include/xsm/xsm.h    |  1 -
 xen/xsm/flask/flask_op.c |  4 +---
 xen/xsm/flask/hooks.c    |  3 ---
 xen/xsm/xsm_core.c       | 16 ----------------
 4 files changed, 1 insertion(+), 23 deletions(-)

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 0d525ec..4b8843d 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -750,7 +750,6 @@ extern bool has_xsm_magic(paddr_t);
 #endif
 
 extern int register_xsm(struct xsm_operations *ops);
-extern int unregister_xsm(struct xsm_operations *ops);
 
 extern struct xsm_operations dummy_xsm_ops;
 extern void xsm_fixup_ops(struct xsm_operations *ops);
diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
index 3ad4bdc..719c2d7 100644
--- a/xen/xsm/flask/flask_op.c
+++ b/xen/xsm/flask/flask_op.c
@@ -58,8 +58,6 @@ static int flask_security_make_bools(void);
 
 extern int ss_initialized;
 
-extern struct xsm_operations *original_ops;
-
 static void __init parse_flask_param(char *s)
 {
     if ( !strcmp(s, "enforcing") )
@@ -243,7 +241,7 @@ static int flask_disable(void)
     flask_disabled = 1;
 
     /* Reset xsm_ops to the original module. */
-    xsm_ops = original_ops;
+    xsm_ops = &dummy_xsm_ops;
 
     return 0;
 }
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 596ac0a..5e81ed4 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -35,8 +35,6 @@
 #include <objsec.h>
 #include <conditional.h>
 
-struct xsm_operations *original_ops = NULL;
-
 static u32 domain_sid(struct domain *dom)
 {
     struct domain_security_struct *dsec = dom->ssid;
@@ -1841,7 +1839,6 @@ __init void flask_init(void)
 
     avc_init();
 
-    original_ops = xsm_ops;
     if ( register_xsm(&flask_ops) )
         panic("Flask: Unable to register with XSM");
 
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 2c4d576..4a264c2 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -149,22 +149,6 @@ int __init register_xsm(struct xsm_operations *ops)
     return 0;
 }
 
-
-int unregister_xsm(struct xsm_operations *ops)
-{
-    if ( ops != xsm_ops )
-    {
-        printk("%s: trying to unregister "
-               "a security_opts structure that is not "
-               "registered, failing.\n", __FUNCTION__);
-        return -EINVAL;
-    }
-
-    xsm_ops = &dummy_xsm_ops;
-
-    return 0;
-}
-
 #endif
 
 long do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
-- 
2.5.5


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

Re: [PATCH 14/15] xsm: clean up unregistration

[Andrew Cooper]

On 09/06/16 15:47, Daniel De Graaf wrote:
> The only possible value of original_ops was &dummy_xsm_ops, and
> unregister_xsm was never used.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

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

Re: [PATCH 14/15] xsm: clean up unregistration

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:17AM -0400, Daniel De Graaf wrote:
> The only possible value of original_ops was &dummy_xsm_ops, and
> unregister_xsm was never used.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

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

> ---
>  xen/include/xsm/xsm.h    |  1 -
>  xen/xsm/flask/flask_op.c |  4 +---
>  xen/xsm/flask/hooks.c    |  3 ---
>  xen/xsm/xsm_core.c       | 16 ----------------
>  4 files changed, 1 insertion(+), 23 deletions(-)
> 
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index 0d525ec..4b8843d 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -750,7 +750,6 @@ extern bool has_xsm_magic(paddr_t);
>  #endif
>  
>  extern int register_xsm(struct xsm_operations *ops);
> -extern int unregister_xsm(struct xsm_operations *ops);
>  
>  extern struct xsm_operations dummy_xsm_ops;
>  extern void xsm_fixup_ops(struct xsm_operations *ops);
> diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
> index 3ad4bdc..719c2d7 100644
> --- a/xen/xsm/flask/flask_op.c
> +++ b/xen/xsm/flask/flask_op.c
> @@ -58,8 +58,6 @@ static int flask_security_make_bools(void);
>  
>  extern int ss_initialized;
>  
> -extern struct xsm_operations *original_ops;
> -
>  static void __init parse_flask_param(char *s)
>  {
>      if ( !strcmp(s, "enforcing") )
> @@ -243,7 +241,7 @@ static int flask_disable(void)
>      flask_disabled = 1;
>  
>      /* Reset xsm_ops to the original module. */
> -    xsm_ops = original_ops;
> +    xsm_ops = &dummy_xsm_ops;
>  
>      return 0;
>  }
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 596ac0a..5e81ed4 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -35,8 +35,6 @@
>  #include <objsec.h>
>  #include <conditional.h>
>  
> -struct xsm_operations *original_ops = NULL;
> -
>  static u32 domain_sid(struct domain *dom)
>  {
>      struct domain_security_struct *dsec = dom->ssid;
> @@ -1841,7 +1839,6 @@ __init void flask_init(void)
>  
>      avc_init();
>  
> -    original_ops = xsm_ops;
>      if ( register_xsm(&flask_ops) )
>          panic("Flask: Unable to register with XSM");
>  
> diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
> index 2c4d576..4a264c2 100644
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -149,22 +149,6 @@ int __init register_xsm(struct xsm_operations *ops)
>      return 0;
>  }
>  
> -
> -int unregister_xsm(struct xsm_operations *ops)
> -{
> -    if ( ops != xsm_ops )
> -    {
> -        printk("%s: trying to unregister "
> -               "a security_opts structure that is not "
> -               "registered, failing.\n", __FUNCTION__);
> -        return -EINVAL;
> -    }
> -
> -    xsm_ops = &dummy_xsm_ops;
> -
> -    return 0;
> -}
> -
>  #endif
>  
>  long do_xsm_op (XEN_GUEST_HANDLE_PARAM(xsm_op_t) op)
> -- 
> 2.5.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[PATCH 15/15] xsm: add a default policy to .init.data

[Daniel De Graaf]

This adds a Kconfig option and support for including the XSM policy from
tools/flask/policy in the hypervisor so that the bootloader does not
need to provide a policy to get sane behavior from an XSM-enabled
hypervisor.  The policy provided by the bootloader, if present, will
override the built-in policy.

Enabling this option only builds the policy if checkpolicy is available
during compilation of the hypervisor; otherwise, it does nothing.  The
XSM policy is not moved out of tools because that remains the primary
location for installing and configuring the policy.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xen-command-line.markdown | 16 +++++++++-------
 docs/misc/xsm-flask.txt             | 30 +++++++++++++++---------------
 xen/arch/arm/xen.lds.S              |  4 ++++
 xen/arch/x86/xen.lds.S              |  5 +++++
 xen/common/Kconfig                  | 17 +++++++++++++++++
 xen/xsm/flask/Makefile              | 17 +++++++++++++++++
 xen/xsm/xsm_core.c                  | 12 ++++++++++++
 7 files changed, 79 insertions(+), 22 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown
index fed732c..c85d1dc 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -704,13 +704,15 @@ enabled by running either:
   with untrusted guests.  If a policy is provided by the bootloader, it will be
   loaded; errors will be reported to the ring buffer but will not prevent
   booting.  The policy can be changed to enforcing mode using "xl setenforce".
-* `enforcing`: This requires a security policy to be provided by the bootloader
-  and will enter enforcing mode prior to the creation of domain 0.  If a valid
-  policy is not provided, the hypervisor will not continue booting.
-* `late`: This disables loading of the security policy from the bootloader.
-  FLASK will be enabled but will not enforce access controls until a policy is
-  loaded by a domain using "xl loadpolicy".  Once a policy is loaded, FLASK will
-  run in enforcing mode unless "xl setenforce" has changed that setting.
+* `enforcing`: This will cause the security server to enter enforcing mode prior
+  to the creation of domain 0.  If an valid policy is not provided by the
+  bootloader and no built-in policy is present, the hypervisor will not continue
+  booting.
+* `late`: This disables loading of the built-in security policy or the policy
+  provided by the bootloader.  FLASK will be enabled but will not enforce access
+  controls until a policy is loaded by a domain using "xl loadpolicy".  Once a
+  policy is loaded, FLASK will run in enforcing mode unless "xl setenforce" has
+  changed that setting.
 * `disabled`: This causes the XSM framework to revert to the dummy module.  The
   dummy module provides the same security policy as is used when compiling the
   hypervisor without support for XSM.  The xsm\_op hypercall can also be used to
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 2f42585..62f15dd 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -141,21 +141,21 @@ only type enforcement is used and the user and role are set to system_u and
 system_r for all domains.
 
 The FLASK security framework is mostly configured using a security policy file.
-This policy file is not normally generated during the Xen build process because
-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. 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.
-Once dom0 is running, the policy can be reloaded using "xl loadpolicy".
+It relies on the SELinux compiler "checkpolicy"; if this is available, the
+policy will be compiled as part of the tools build.  If hypervisor support for a
+built-in policy is enabled ("Compile Xen with a built-in security policy"), the
+policy will be built during the hypervisor build.
+
+The policy is generated from definition files in tools/flask/policy.  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.
+
+If not using the built-in policy, the XSM policy file needs to be copied to
+/boot and loaded as a module by grub.  The exact position and filename 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.  Once dom0 is running,
+the policy can be reloaded using "xl loadpolicy".
 
 The example policy included with Xen demonstrates most of the features of FLASK
 that can be used without dom0 disaggregation. The main types for domUs are:
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 8320381..80c2299 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -139,6 +139,10 @@ SECTIONS
        *(.init.data.rel)
        *(.init.data.rel.*)
 
+       __xsm_init_policy_start = .;
+       *(.init.xsm_policy)
+       __xsm_init_policy_end = .;
+
        . = ALIGN(8);
        __ctors_start = .;
        *(.init_array)
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index dcbb8fe..9072e1c 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -155,6 +155,11 @@ SECTIONS
        *(.init.data)
        *(.init.data.rel)
        *(.init.data.rel.*)
+
+       __xsm_init_policy_start = .;
+       *(.init.xsm_policy)
+       __xsm_init_policy_end = .;
+
        . = ALIGN(4);
        __trampoline_rel_start = .;
        *(.trampoline_rel)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index b8f1800..ae489a7 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -132,6 +132,23 @@ config FLASK
 
 	  If unsure, say Y.
 
+config XSM_POLICY
+	bool "Compile Xen with a built-in security policy"
+	default y
+	depends on XSM
+	---help---
+	  This includes a default XSM policy in the hypervisor so that the
+	  bootloader does not need to load a policy to get sane behavior from an
+	  XSM-enabled hypervisor.  If this is disabled, a policy must be
+	  provided by the bootloader or by Domain 0.  Even if this is enabled, a
+	  policy provided by the bootloader will override it.
+
+	  This requires that the SELinux policy compiler (checkpolicy) be
+	  available when compiling the hypervisor; if this tool is not found, no
+	  policy will be added.
+
+	  If unsure, say Y.
+
 config FLASK_AVC_STATS
 	def_bool y
 	depends on FLASK
diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile
index 12fc3a9..eefd37c 100644
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -27,6 +27,23 @@ $(FLASK_H_FILES): $(FLASK_H_DEPEND)
 $(AV_H_FILES): $(AV_H_DEPEND)
 	$(CONFIG_SHELL) policy/mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
 
+ifeq ($(CONFIG_XSM_POLICY),y)
+HAS_CHECKPOLICY := $(shell checkpolicy -h 2>&1 | grep -q xen && echo y || echo n)
+
+obj-$(HAS_CHECKPOLICY) += policy.o
+endif
+
+LDFLAGS += --accept-unknown-input-arch
+
+POLICY_SRC := $(XEN_ROOT)/tools/flask/policy/xenpolicy-$(XEN_FULLVERSION)
+
+policy.bin: FORCE
+	$(MAKE) -C $(XEN_ROOT)/tools/flask/policy
+	cmp -s $(POLICY_SRC) $@ || cp $(POLICY_SRC) $@
+
+policy.o: policy.bin
+	$(OBJCOPY) -S -I binary -O elf64-little --rename-section=.data=.init.xsm_policy $< $@
+
 .PHONY: clean
 clean::
 	rm -f $(ALL_H_FILES) *.o $(DEPS)
diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
index 4a264c2..6ffccb2 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -36,6 +36,17 @@ static inline int verify(struct xsm_operations *ops)
     return 0;
 }
 
+extern char __xsm_init_policy_start[], __xsm_init_policy_end[];
+
+static void __init xsm_policy_init(void)
+{
+    if ( policy_size == 0 && __xsm_init_policy_end != __xsm_init_policy_start )
+    {
+        policy_buffer = __xsm_init_policy_start;
+        policy_size = __xsm_init_policy_end - __xsm_init_policy_start;
+    }
+}
+
 static void __init do_xsm_initcalls(void)
 {
     flask_init();
@@ -51,6 +62,7 @@ static int __init xsm_core_init(void)
     }
 
     xsm_ops = &dummy_xsm_ops;
+    xsm_policy_init();
     do_xsm_initcalls();
 
     return 0;
-- 
2.5.5


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

Re: [PATCH 15/15] xsm: add a default policy to .init.data

[Andrew Cooper]

On 09/06/16 15:47, Daniel De Graaf wrote:
> diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
> index 4a264c2..6ffccb2 100644
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -36,6 +36,17 @@ static inline int verify(struct xsm_operations *ops)
>      return 0;
>  }
>  
> +extern char __xsm_init_policy_start[], __xsm_init_policy_end[];
> +
> +static void __init xsm_policy_init(void)
> +{
> +    if ( policy_size == 0 && __xsm_init_policy_end != __xsm_init_policy_start )
> +    {
> +        policy_buffer = __xsm_init_policy_start;

I think this might cause a problem for ARM.

xsm_dt_init(void) does

ret = xsm_core_init();
xfree(policy_buffer);

which might now try freeing a piece of initdata.  Even going back to c/s
a8f2fb51c19 which introduced this code, I can't spot its justification.


It also looks like the entire policy buffer can be const, at which point
it can be linked slightly higher in .init.data with the other
logically-const data.

~Andrew

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

Re: [PATCH 15/15] xsm: add a default policy to .init.data

[Daniel De Graaf]

On 06/09/2016 11:30 AM, Andrew Cooper wrote:
> On 09/06/16 15:47, Daniel De Graaf wrote:
>> diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
>> index 4a264c2..6ffccb2 100644
>> --- a/xen/xsm/xsm_core.c
>> +++ b/xen/xsm/xsm_core.c
>> @@ -36,6 +36,17 @@ static inline int verify(struct xsm_operations *ops)
>>      return 0;
>>  }
>>
>> +extern char __xsm_init_policy_start[], __xsm_init_policy_end[];
>> +
>> +static void __init xsm_policy_init(void)
>> +{
>> +    if ( policy_size == 0 && __xsm_init_policy_end != __xsm_init_policy_start )
>> +    {
>> +        policy_buffer = __xsm_init_policy_start;
>
> I think this might cause a problem for ARM.
>
> xsm_dt_init(void) does
>
> ret = xsm_core_init();
> xfree(policy_buffer);
>
> which might now try freeing a piece of initdata.  Even going back to c/s
> a8f2fb51c19 which introduced this code, I can't spot its justification.

The buffer is allocated and populated in xsm_dt_policy_init.

> It also looks like the entire policy buffer can be const, at which point
> it can be linked slightly higher in .init.data with the other
> logically-const data.

Sure, although this will require quite a bit of const propagation down into
the FLASK security server (or casting it away).

-- 
Daniel De Graaf
National Security Agency

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

Re: [PATCH 15/15] xsm: add a default policy to .init.data

[Jan Beulich]

>>> On 09.06.16 at 18:58, <dgdegra@tycho.nsa.gov> wrote:
> On 06/09/2016 11:30 AM, Andrew Cooper wrote:
>> On 09/06/16 15:47, Daniel De Graaf wrote:
>>> diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
>>> index 4a264c2..6ffccb2 100644
>>> --- a/xen/xsm/xsm_core.c
>>> +++ b/xen/xsm/xsm_core.c
>>> @@ -36,6 +36,17 @@ static inline int verify(struct xsm_operations *ops)
>>>      return 0;
>>>  }
>>>
>>> +extern char __xsm_init_policy_start[], __xsm_init_policy_end[];
>>> +
>>> +static void __init xsm_policy_init(void)
>>> +{
>>> +    if ( policy_size == 0 && __xsm_init_policy_end != __xsm_init_policy_start )
>>> +    {
>>> +        policy_buffer = __xsm_init_policy_start;
>>
>> I think this might cause a problem for ARM.
>>
>> xsm_dt_init(void) does
>>
>> ret = xsm_core_init();
>> xfree(policy_buffer);
>>
>> which might now try freeing a piece of initdata.  Even going back to c/s
>> a8f2fb51c19 which introduced this code, I can't spot its justification.
> 
> The buffer is allocated and populated in xsm_dt_policy_init.

Only if there is an XSM module; I think Andrew refers to the
assignment to policy_buffer still visible above, which would
remain untouched by xsm_dt_policy_init() if bailing early.

>> It also looks like the entire policy buffer can be const, at which point
>> it can be linked slightly higher in .init.data with the other
>> logically-const data.
> 
> Sure, although this will require quite a bit of const propagation down into
> the FLASK security server (or casting it away).

No casting away of constness please, except in very special situations
(which this one pretty clearly isn't).

Jan


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

Re: [PATCH 15/15] xsm: add a default policy to .init.data

[Jan Beulich]

>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -132,6 +132,23 @@ config FLASK
>  
>  	  If unsure, say Y.
>  
> +config XSM_POLICY
> +	bool "Compile Xen with a built-in security policy"
> +	default y
> +	depends on XSM
> +	---help---
> +	  This includes a default XSM policy in the hypervisor so that the
> +	  bootloader does not need to load a policy to get sane behavior from an
> +	  XSM-enabled hypervisor.  If this is disabled, a policy must be
> +	  provided by the bootloader or by Domain 0.  Even if this is enabled, a
> +	  policy provided by the bootloader will override it.
> +
> +	  This requires that the SELinux policy compiler (checkpolicy) be
> +	  available when compiling the hypervisor; if this tool is not found, no
> +	  policy will be added.
> +
> +	  If unsure, say Y.
> +
>  config FLASK_AVC_STATS
>  	def_bool y
>  	depends on FLASK

Placing this between FLASK and FLASK_AVC_STATS will break proper
menuconfig representation of the latter afaict.

Jan


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

Re: [PATCH 15/15] xsm: add a default policy to .init.data

[Daniel De Graaf]

On 06/09/2016 12:15 PM, Jan Beulich wrote:
>>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -132,6 +132,23 @@ config FLASK
>>
>>  	  If unsure, say Y.
>>
>> +config XSM_POLICY
>> +	bool "Compile Xen with a built-in security policy"
>> +	default y
>> +	depends on XSM
>> +	---help---
>> +	  This includes a default XSM policy in the hypervisor so that the
>> +	  bootloader does not need to load a policy to get sane behavior from an
>> +	  XSM-enabled hypervisor.  If this is disabled, a policy must be
>> +	  provided by the bootloader or by Domain 0.  Even if this is enabled, a
>> +	  policy provided by the bootloader will override it.
>> +
>> +	  This requires that the SELinux policy compiler (checkpolicy) be
>> +	  available when compiling the hypervisor; if this tool is not found, no
>> +	  policy will be added.
>> +
>> +	  If unsure, say Y.
>> +
>>  config FLASK_AVC_STATS
>>  	def_bool y
>>  	depends on FLASK
>
> Placing this between FLASK and FLASK_AVC_STATS will break proper
> menuconfig representation of the latter afaict.
>
> Jan

This option isn't visible in menuconfig.  Should I make it visible?

-- 
Daniel De Graaf
National Security Agency

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

Re: [PATCH 15/15] xsm: add a default policy to .init.data

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 1508 bytes --]

On 6/9/16 11:53 AM, Daniel De Graaf wrote:
> On 06/09/2016 12:15 PM, Jan Beulich wrote:
>>>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -132,6 +132,23 @@ config FLASK
>>>
>>>        If unsure, say Y.
>>>
>>> +config XSM_POLICY
>>> +    bool "Compile Xen with a built-in security policy"
>>> +    default y
>>> +    depends on XSM
>>> +    ---help---
>>> +      This includes a default XSM policy in the hypervisor so that the
>>> +      bootloader does not need to load a policy to get sane behavior
>>> from an
>>> +      XSM-enabled hypervisor.  If this is disabled, a policy must be
>>> +      provided by the bootloader or by Domain 0.  Even if this is
>>> enabled, a
>>> +      policy provided by the bootloader will override it.
>>> +
>>> +      This requires that the SELinux policy compiler (checkpolicy) be
>>> +      available when compiling the hypervisor; if this tool is not
>>> found, no
>>> +      policy will be added.
>>> +
>>> +      If unsure, say Y.
>>> +
>>>  config FLASK_AVC_STATS
>>>      def_bool y
>>>      depends on FLASK
>>
>> Placing this between FLASK and FLASK_AVC_STATS will break proper
>> menuconfig representation of the latter afaict.
>>
>> Jan
> 
> This option isn't visible in menuconfig.  Should I make it visible?
> 

I believe I actually had that as an outstanding question to you on the
series that introduced that flag.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [PATCH 15/15] xsm: add a default policy to .init.data

[Daniel De Graaf]

On 06/09/2016 05:54 PM, Doug Goldstein wrote:
> On 6/9/16 11:53 AM, Daniel De Graaf wrote:
>> On 06/09/2016 12:15 PM, Jan Beulich wrote:
>>>>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
>>>> --- a/xen/common/Kconfig
>>>> +++ b/xen/common/Kconfig
>>>> @@ -132,6 +132,23 @@ config FLASK
>>>>
>>>>        If unsure, say Y.
>>>>
>>>> +config XSM_POLICY
>>>> +    bool "Compile Xen with a built-in security policy"
>>>> +    default y
>>>> +    depends on XSM
>>>> +    ---help---
>>>> +      This includes a default XSM policy in the hypervisor so that the
>>>> +      bootloader does not need to load a policy to get sane behavior
>>>> from an
>>>> +      XSM-enabled hypervisor.  If this is disabled, a policy must be
>>>> +      provided by the bootloader or by Domain 0.  Even if this is
>>>> enabled, a
>>>> +      policy provided by the bootloader will override it.
>>>> +
>>>> +      This requires that the SELinux policy compiler (checkpolicy) be
>>>> +      available when compiling the hypervisor; if this tool is not
>>>> found, no
>>>> +      policy will be added.
>>>> +
>>>> +      If unsure, say Y.
>>>> +
>>>>  config FLASK_AVC_STATS
>>>>      def_bool y
>>>>      depends on FLASK
>>>
>>> Placing this between FLASK and FLASK_AVC_STATS will break proper
>>> menuconfig representation of the latter afaict.
>>>
>>> Jan
>>
>> This option isn't visible in menuconfig.  Should I make it visible?
>>
>
> I believe I actually had that as an outstanding question to you on the
> series that introduced that flag.

At the time I didn't see the need for it to be visible.  Since it's come
up again, I think it should either be made visible (in a distinct patch),
but maybe limited to EXPERT=y.  Otherwise, it seems like the option and
its #ifdefs should be removed: there's no point in having the option if
it's not possible to adjust it.

-- 
Daniel De Graaf
National Security Agency

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

Re: [PATCH 15/15] xsm: add a default policy to .init.data

[Jan Beulich]

>>> On 09.06.16 at 18:53, <dgdegra@tycho.nsa.gov> wrote:
> On 06/09/2016 12:15 PM, Jan Beulich wrote:
>>>>> On 09.06.16 at 16:47, <dgdegra@tycho.nsa.gov> wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -132,6 +132,23 @@ config FLASK
>>>
>>>  	  If unsure, say Y.
>>>
>>> +config XSM_POLICY
>>> +	bool "Compile Xen with a built-in security policy"
>>> +	default y
>>> +	depends on XSM
>>> +	---help---
>>> +	  This includes a default XSM policy in the hypervisor so that the
>>> +	  bootloader does not need to load a policy to get sane behavior from an
>>> +	  XSM-enabled hypervisor.  If this is disabled, a policy must be
>>> +	  provided by the bootloader or by Domain 0.  Even if this is enabled, a
>>> +	  policy provided by the bootloader will override it.
>>> +
>>> +	  This requires that the SELinux policy compiler (checkpolicy) be
>>> +	  available when compiling the hypervisor; if this tool is not found, no
>>> +	  policy will be added.
>>> +
>>> +	  If unsure, say Y.
>>> +
>>>  config FLASK_AVC_STATS
>>>  	def_bool y
>>>  	depends on FLASK
>>
>> Placing this between FLASK and FLASK_AVC_STATS will break proper
>> menuconfig representation of the latter afaict.
> 
> This option isn't visible in menuconfig.  Should I make it visible?

Ah, true. No, it shouldn't become visible now, but since it may
become visible eventually I'd still prefer if the ordering was
done as if all options having some dependency also had a prompt
(reducing future code churn).

Jan


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

Re: [PATCH 15/15] xsm: add a default policy to .init.data

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:18AM -0400, Daniel De Graaf wrote:
> This adds a Kconfig option and support for including the XSM policy from
> tools/flask/policy in the hypervisor so that the bootloader does not
> need to provide a policy to get sane behavior from an XSM-enabled
> hypervisor.  The policy provided by the bootloader, if present, will
> override the built-in policy.
> 
> Enabling this option only builds the policy if checkpolicy is available
> during compilation of the hypervisor; otherwise, it does nothing.  The
> XSM policy is not moved out of tools because that remains the primary
> location for installing and configuring the policy.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

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

Thanks!

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

Re: [PATCH 00/15] XSM/FLASK updates for 4.8

[Konrad Rzeszutek Wilk]

On Thu, Jun 09, 2016 at 10:47:03AM -0400, Daniel De Graaf wrote:
> Some of these patches have been posted before (patch 11 was posted in
> 2014; an earlier variant of 1-6 and 15 were posted recently as RFC).
> The rest are mostly removal of unused code or other cleanup.

Hey Daniel,

I reviewed most (all?) of the patches. Thanks for posting them!
> 
> FLASK policy updates:
> [PATCH 01/15] flask/policy: split into modules
> [PATCH 02/15] flask/policy: split out rules for system_r
> [PATCH 03/15] flask/policy: move user definitions and constraints
> [PATCH 04/15] flask/policy: remove unused support for binary modules
> [PATCH 05/15] flask/policy: xenstore stubdom policy
> [PATCH 06/15] flask/policy: remove unused example
> 
> Hypervisor updates to the FLASK security server:
> [PATCH 07/15] flask: unify {get,set}vcpucontext permissions
> [PATCH 08/15] flask: remove unused secondary context in ocontext
> [PATCH 09/15] flask: remove unused AVC callback functions
> [PATCH 10/15] flask: remove xen_flask_userlist operation
> [PATCH 11/15] flask: improve unknown permission handling
> 
> Hypervisor updates to the XSM framework:
> [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section
> [PATCH 13/15] xsm: annotate setup functions with __init
> [PATCH 14/15] xsm: clean up unregistration
> [PATCH 15/15] xsm: add a default policy to .init.data
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [PATCH 00/15] XSM/FLASK updates for 4.8

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 2089 bytes --]

On 6/9/16 9:47 AM, Daniel De Graaf wrote:
> Some of these patches have been posted before (patch 11 was posted in
> 2014; an earlier variant of 1-6 and 15 were posted recently as RFC).
> The rest are mostly removal of unused code or other cleanup.
> 
> FLASK policy updates:
> [PATCH 01/15] flask/policy: split into modules
> [PATCH 02/15] flask/policy: split out rules for system_r
> [PATCH 03/15] flask/policy: move user definitions and constraints
> [PATCH 04/15] flask/policy: remove unused support for binary modules
> [PATCH 05/15] flask/policy: xenstore stubdom policy
> [PATCH 06/15] flask/policy: remove unused example
> 
> Hypervisor updates to the FLASK security server:
> [PATCH 07/15] flask: unify {get,set}vcpucontext permissions
> [PATCH 08/15] flask: remove unused secondary context in ocontext
> [PATCH 09/15] flask: remove unused AVC callback functions
> [PATCH 10/15] flask: remove xen_flask_userlist operation
> [PATCH 11/15] flask: improve unknown permission handling
> 
> Hypervisor updates to the XSM framework:
> [PATCH 12/15] xen/xsm: remove .xsm_initcall.init section
> [PATCH 13/15] xsm: annotate setup functions with __init
> [PATCH 14/15] xsm: clean up unregistration
> [PATCH 15/15] xsm: add a default policy to .init.data
> 

I've reviewed the whole series at this point. I'd honestly like to see
at least the first 6 patches land into staging at this point. There's
two R-b's (mine and Konrad's) and no comments that would imply a change
needs to happen. Those 6 stand on their own as well. There are no ACKs
since Daniel is the only maintainer for those changes.

I can rebase some changes I've got locally for a custom policy (honestly
Daniel's changes will make it easier/better for me) and give it a full
on test Monday morning if there is any concerns.

The other patches in the series can mostly get my R-b as well. I do have
some of the same comments / concerns that have already been brought up
so I'll go through and add my R-b to the clean patches and wait for a v2
of the others.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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