* [PATCH 01/17] flask/policy: split into modules
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:04 ` [PATCH 02/17] flask/policy: split out rules for system_r Daniel De Graaf
` (16 subsequent siblings)
17 siblings, 0 replies; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: 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>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
---
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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH 02/17] flask/policy: split out rules for system_r
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
2016-06-20 14:04 ` [PATCH 01/17] flask/policy: split into modules Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:04 ` [PATCH 03/17] flask/policy: move user definitions and constraints into modules Daniel De Graaf
` (15 subsequent siblings)
17 siblings, 0 replies; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: 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>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
---
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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH 03/17] flask/policy: move user definitions and constraints into modules
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
2016-06-20 14:04 ` [PATCH 01/17] flask/policy: split into modules Daniel De Graaf
2016-06-20 14:04 ` [PATCH 02/17] flask/policy: split out rules for system_r Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:04 ` [PATCH 04/17] flask/policy: remove unused support for binary modules Daniel De Graaf
` (14 subsequent siblings)
17 siblings, 0 replies; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf
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>
---
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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH 04/17] flask/policy: remove unused support for binary modules
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (2 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 03/17] flask/policy: move user definitions and constraints into modules Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:04 ` [PATCH 05/17] flask/policy: xenstore stubdom policy Daniel De Graaf
` (13 subsequent siblings)
17 siblings, 0 replies; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf
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>
---
.../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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH 05/17] flask/policy: xenstore stubdom policy
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (3 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 04/17] flask/policy: remove unused support for binary modules Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:04 ` [PATCH 06/17] flask/policy: remove unused example Daniel De Graaf
` (12 subsequent siblings)
17 siblings, 0 replies; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf
This adds the xenstore_t type to the example policy for use by a
xenstore stub domain; see the init-xenstore-domain tool for how this
type needs to be used.
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>
---
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..6dba0a3 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 (see init-xenstore-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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH 06/17] flask/policy: remove unused example
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (4 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 05/17] flask/policy: xenstore stubdom policy Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:04 ` [PATCH 07/17] flask: unify {get, set}vcpucontext permissions Daniel De Graaf
` (11 subsequent siblings)
17 siblings, 0 replies; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf
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>
Reviewed-by: Doug Goldstein <cardoe@cardoe.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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH 07/17] flask: unify {get, set}vcpucontext permissions
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (5 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 06/17] flask/policy: remove unused example Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:27 ` Doug Goldstein
2016-06-20 14:04 ` [PATCH 08/17] flask: remove unused secondary context in ocontext Daniel De Graaf
` (10 subsequent siblings)
17 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: 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>
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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH 07/17] flask: unify {get, set}vcpucontext permissions
2016-06-20 14:04 ` [PATCH 07/17] flask: unify {get, set}vcpucontext permissions Daniel De Graaf
@ 2016-06-20 14:27 ` Doug Goldstein
2016-06-20 14:35 ` Andrew Cooper
0 siblings, 1 reply; 58+ messages in thread
From: Doug Goldstein @ 2016-06-20 14:27 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel, Andrew Cooper
[-- Attachment #1.1.1: Type: text/plain, Size: 653 bytes --]
On 6/20/16 9:04 AM, 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.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
I'm a:
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
But I'd like to see Andrew Cooper's R-b or comments 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
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH 07/17] flask: unify {get, set}vcpucontext permissions
2016-06-20 14:27 ` Doug Goldstein
@ 2016-06-20 14:35 ` Andrew Cooper
2016-06-20 14:50 ` Daniel De Graaf
0 siblings, 1 reply; 58+ messages in thread
From: Andrew Cooper @ 2016-06-20 14:35 UTC (permalink / raw)
To: Doug Goldstein, Daniel De Graaf, xen-devel
On 20/06/16 15:27, Doug Goldstein wrote:
> On 6/20/16 9:04 AM, 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.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> I'm a:
>
> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
>
> But I'd like to see Andrew Cooper's R-b or comments as well.
>
I agree. I can't see a plausible usecase for an entity being entitled
to read vcpu content, but not to modify it.
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH 07/17] flask: unify {get, set}vcpucontext permissions
2016-06-20 14:35 ` Andrew Cooper
@ 2016-06-20 14:50 ` Daniel De Graaf
2016-06-20 14:58 ` Andrew Cooper
0 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:50 UTC (permalink / raw)
To: Andrew Cooper, Doug Goldstein, xen-devel
On 06/20/2016 10:35 AM, Andrew Cooper wrote:
> On 20/06/16 15:27, Doug Goldstein wrote:
>> On 6/20/16 9:04 AM, 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.
>>>
>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> I'm a:
>>
>> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
>>
>> But I'd like to see Andrew Cooper's R-b or comments as well.
>>
>
> I agree. I can't see a plausible usecase for an entity being entitled
> to read vcpu content, but not to modify it.
>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
That's not exactly what this patch does: the get and set permissions
are still split, but unified across the different types of registers.
Where previously there were 6 permissions, now there are 2.
A use case where you would be entitled to read but not modify is a
monitoring domain (remote virus scanner, for example) which needs
read access to scan but does not do remediation itself.
--
Daniel De Graaf
National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH 07/17] flask: unify {get, set}vcpucontext permissions
2016-06-20 14:50 ` Daniel De Graaf
@ 2016-06-20 14:58 ` Andrew Cooper
0 siblings, 0 replies; 58+ messages in thread
From: Andrew Cooper @ 2016-06-20 14:58 UTC (permalink / raw)
To: Daniel De Graaf, Doug Goldstein, xen-devel
On 20/06/16 15:50, Daniel De Graaf wrote:
> On 06/20/2016 10:35 AM, Andrew Cooper wrote:
>> On 20/06/16 15:27, Doug Goldstein wrote:
>>> On 6/20/16 9:04 AM, 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.
>>>>
>>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>> I'm a:
>>>
>>> Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
>>>
>>> But I'd like to see Andrew Cooper's R-b or comments as well.
>>>
>>
>> I agree. I can't see a plausible usecase for an entity being entitled
>> to read vcpu content, but not to modify it.
>>
>> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
> That's not exactly what this patch does: the get and set permissions
> are still split, but unified across the different types of registers.
> Where previously there were 6 permissions, now there are 2.
The boundaries for those hypercalls were somewhat arbitrary, and
definitely awkward to use. Some information is duplicated between
them. I plan to make them all disappear, in favour of something more
consistent when altering the migration stream semantics.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 08/17] flask: remove unused secondary context in ocontext
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (6 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 07/17] flask: unify {get, set}vcpucontext permissions Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:30 ` Doug Goldstein
2016-06-20 14:04 ` [PATCH 09/17] flask: remove unused AVC callback functions Daniel De Graaf
` (9 subsequent siblings)
17 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: 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 | 21 ++++++++--------
xen/xsm/flask/ss/policydb.h | 4 ++--
xen/xsm/flask/ss/services.c | 58 ++++++++++++++++++++++-----------------------
3 files changed, 41 insertions(+), 42 deletions(-)
diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index eebfe9c..00b5390 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -638,8 +638,7 @@ 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]);
+ context_destroy(&c->context);
if ( i == OCON_ISID || i == OCON_DTREE )
xfree(c->u.name);
xfree(c);
@@ -747,14 +746,14 @@ int policydb_load_isids(struct policydb *p, struct sidtab *s)
head = p->ocontexts[OCON_ISID];
for ( c = head; c; c = c->next )
{
- if ( !c->context[0].user )
+ if ( !c->context.user )
{
printk(KERN_ERR "Flask: SID %s was never "
"defined.\n", c->u.name);
rc = -EINVAL;
goto out;
}
- if ( sidtab_insert(s, c->sid[0], &c->context[0]) )
+ if ( sidtab_insert(s, c->sid, &c->context) )
{
printk(KERN_ERR "Flask: unable to load initial "
"SID %s.\n", c->u.name);
@@ -2015,8 +2014,8 @@ int policydb_read(struct policydb *p, void *fp)
rc = next_entry(buf, fp, sizeof(u32));
if ( rc < 0 )
goto bad;
- c->sid[0] = le32_to_cpu(buf[0]);
- rc = context_read_and_validate(&c->context[0], p, fp);
+ c->sid = le32_to_cpu(buf[0]);
+ rc = context_read_and_validate(&c->context, p, fp);
if ( rc )
goto bad;
break;
@@ -2031,7 +2030,7 @@ int policydb_read(struct policydb *p, void *fp)
if ( rc < 0 )
goto bad;
c->u.pirq = le32_to_cpu(buf[0]);
- rc = context_read_and_validate(&c->context[0], p, fp);
+ rc = context_read_and_validate(&c->context, p, fp);
if ( rc )
goto bad;
break;
@@ -2047,7 +2046,7 @@ int policydb_read(struct policydb *p, void *fp)
goto bad;
c->u.ioport.low_ioport = le32_to_cpu(buf[0]);
c->u.ioport.high_ioport = le32_to_cpu(buf[1]);
- rc = context_read_and_validate(&c->context[0], p, fp);
+ rc = context_read_and_validate(&c->context, p, fp);
if ( rc )
goto bad;
break;
@@ -2075,7 +2074,7 @@ int policydb_read(struct policydb *p, void *fp)
c->u.iomem.low_iomem = le32_to_cpu(buf[0]);
c->u.iomem.high_iomem = le32_to_cpu(buf[1]);
}
- rc = context_read_and_validate(&c->context[0], p, fp);
+ rc = context_read_and_validate(&c->context, p, fp);
if ( rc )
goto bad;
break;
@@ -2090,7 +2089,7 @@ int policydb_read(struct policydb *p, void *fp)
if ( rc < 0 )
goto bad;
c->u.device = le32_to_cpu(buf[0]);
- rc = context_read_and_validate(&c->context[0], p, fp);
+ rc = context_read_and_validate(&c->context, p, fp);
if ( rc )
goto bad;
break;
@@ -2113,7 +2112,7 @@ int policydb_read(struct policydb *p, void *fp)
if ( rc < 0 )
goto bad;
c->u.name[len] = 0;
- rc = context_read_and_validate(&c->context[0], p, fp);
+ rc = context_read_and_validate(&c->context, p, fp);
if ( rc )
goto bad;
break;
diff --git a/xen/xsm/flask/ss/policydb.h b/xen/xsm/flask/ss/policydb.h
index 30be71a..f158ce3 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;
+ u32 sid;
struct ocontext *next;
};
diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 9da358b..c590440 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -1488,13 +1488,13 @@ int security_irq_sid(int pirq, u32 *out_sid)
if ( c )
{
- if ( !c->sid[0] )
+ if ( !c->sid )
{
- rc = sidtab_context_to_sid(&sidtab, &c->context[0], &c->sid[0]);
+ rc = sidtab_context_to_sid(&sidtab, &c->context, &c->sid);
if ( rc )
goto out;
}
- *out_sid = c->sid[0];
+ *out_sid = c->sid;
}
else
{
@@ -1528,13 +1528,13 @@ int security_iomem_sid(unsigned long mfn, u32 *out_sid)
if ( c )
{
- if ( !c->sid[0] )
+ if ( !c->sid )
{
- rc = sidtab_context_to_sid(&sidtab, &c->context[0], &c->sid[0]);
+ rc = sidtab_context_to_sid(&sidtab, &c->context, &c->sid);
if ( rc )
goto out;
}
- *out_sid = c->sid[0];
+ *out_sid = c->sid;
}
else
{
@@ -1559,9 +1559,9 @@ int security_iterate_iomem_sids(unsigned long start, unsigned long end,
c = c->next;
while (c && c->u.iomem.low_iomem <= end) {
- if (!c->sid[0])
+ if (!c->sid)
{
- rc = sidtab_context_to_sid(&sidtab, &c->context[0], &c->sid[0]);
+ rc = sidtab_context_to_sid(&sidtab, &c->context, &c->sid);
if ( rc )
goto out;
}
@@ -1574,11 +1574,11 @@ int security_iterate_iomem_sids(unsigned long start, unsigned long end,
}
if (end <= c->u.iomem.high_iomem) {
/* iteration ends in the middle of this range */
- rc = fn(data, c->sid[0], start, end);
+ rc = fn(data, c->sid, start, end);
goto out;
}
- rc = fn(data, c->sid[0], start, c->u.iomem.high_iomem);
+ rc = fn(data, c->sid, start, c->u.iomem.high_iomem);
if (rc)
goto out;
start = c->u.iomem.high_iomem + 1;
@@ -1616,13 +1616,13 @@ int security_ioport_sid(u32 ioport, u32 *out_sid)
if ( c )
{
- if ( !c->sid[0] )
+ if ( !c->sid )
{
- rc = sidtab_context_to_sid(&sidtab, &c->context[0], &c->sid[0]);
+ rc = sidtab_context_to_sid(&sidtab, &c->context, &c->sid);
if ( rc )
goto out;
}
- *out_sid = c->sid[0];
+ *out_sid = c->sid;
}
else
{
@@ -1647,9 +1647,9 @@ int security_iterate_ioport_sids(u32 start, u32 end,
c = c->next;
while (c && c->u.ioport.low_ioport <= end) {
- if (!c->sid[0])
+ if (!c->sid)
{
- rc = sidtab_context_to_sid(&sidtab, &c->context[0], &c->sid[0]);
+ rc = sidtab_context_to_sid(&sidtab, &c->context, &c->sid);
if ( rc )
goto out;
}
@@ -1662,11 +1662,11 @@ int security_iterate_ioport_sids(u32 start, u32 end,
}
if (end <= c->u.ioport.high_ioport) {
/* iteration ends in the middle of this range */
- rc = fn(data, c->sid[0], start, end);
+ rc = fn(data, c->sid, start, end);
goto out;
}
- rc = fn(data, c->sid[0], start, c->u.ioport.high_ioport);
+ rc = fn(data, c->sid, start, c->u.ioport.high_ioport);
if (rc)
goto out;
start = c->u.ioport.high_ioport + 1;
@@ -1703,13 +1703,13 @@ int security_device_sid(u32 device, u32 *out_sid)
if ( c )
{
- if ( !c->sid[0] )
+ if ( !c->sid )
{
- rc = sidtab_context_to_sid(&sidtab, &c->context[0], &c->sid[0]);
+ rc = sidtab_context_to_sid(&sidtab, &c->context, &c->sid);
if ( rc )
goto out;
}
- *out_sid = c->sid[0];
+ *out_sid = c->sid;
}
else
{
@@ -1849,13 +1849,13 @@ int security_devicetree_sid(const char *path, u32 *out_sid)
if ( c )
{
- if ( !c->sid[0] )
+ if ( !c->sid )
{
- rc = sidtab_context_to_sid(&sidtab, &c->context[0], &c->sid[0]);
+ rc = sidtab_context_to_sid(&sidtab, &c->context, &c->sid);
if ( rc )
goto out;
}
- *out_sid = c->sid[0];
+ *out_sid = c->sid;
}
else
{
@@ -2081,7 +2081,7 @@ int security_ocontext_add( u32 ocon, unsigned long low, unsigned long high
if ( (add = xzalloc(struct ocontext)) == NULL )
return -ENOMEM;
- add->sid[0] = sid;
+ add->sid = sid;
POLICY_WRLOCK;
switch( ocon )
@@ -2099,7 +2099,7 @@ int security_ocontext_add( u32 ocon, unsigned long low, unsigned long high
{
if ( c->u.pirq == add->u.pirq )
{
- if ( c->sid[0] == sid )
+ if ( c->sid == sid )
break;
printk("%s: Duplicate pirq %d\n", __FUNCTION__, add->u.pirq);
ret = -EEXIST;
@@ -2130,7 +2130,7 @@ int security_ocontext_add( u32 ocon, unsigned long low, unsigned long high
if (c && c->u.ioport.low_ioport <= high)
{
if (c->u.ioport.low_ioport == low &&
- c->u.ioport.high_ioport == high && c->sid[0] == sid)
+ c->u.ioport.high_ioport == high && c->sid == sid)
break;
printk("%s: IO Port overlap with entry %#x - %#x\n",
@@ -2164,7 +2164,7 @@ int security_ocontext_add( u32 ocon, unsigned long low, unsigned long high
if (c && c->u.iomem.low_iomem <= high)
{
if (c->u.iomem.low_iomem == low &&
- c->u.iomem.high_iomem == high && c->sid[0] == sid)
+ c->u.iomem.high_iomem == high && c->sid == sid)
break;
printk("%s: IO Memory overlap with entry %#"PRIx64" - %#"PRIx64"\n",
@@ -2195,7 +2195,7 @@ int security_ocontext_add( u32 ocon, unsigned long low, unsigned long high
{
if ( c->u.device == add->u.device )
{
- if ( c->sid[0] == sid )
+ if ( c->sid == sid )
break;
printk("%s: Duplicate PCI Device %#x\n", __FUNCTION__,
@@ -2359,7 +2359,7 @@ int security_devicetree_setlabel(char *path, u32 sid)
xfree(path);
return -ENOMEM;
}
- add->sid[0] = sid;
+ add->sid = sid;
add->u.name = path;
}
else
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH 09/17] flask: remove unused AVC callback functions
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (7 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 08/17] flask: remove unused secondary context in ocontext Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:32 ` Doug Goldstein
2016-06-20 14:04 ` [PATCH 10/17] flask: remove xen_flask_userlist operation Daniel De Graaf
` (8 subsequent siblings)
17 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: 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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH 10/17] flask: remove xen_flask_userlist operation
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (8 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 09/17] flask: remove unused AVC callback functions Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:19 ` Jan Beulich
2016-06-20 14:35 ` Doug Goldstein
2016-06-20 14:04 ` [PATCH 11/17] flask: improve unknown permission handling Daniel De Graaf
` (7 subsequent siblings)
17 siblings, 2 replies; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: 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). In addition,
the information it provides does not actually depend on hypervisor
state (only on the XSM policy), so an application that needs it could
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/xen-compat.h | 2 +-
xen/include/public/xsm/flask_op.h | 6 +-
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 ------------------------------------
10 files changed, 7 insertions(+), 213 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/xen-compat.h b/xen/include/public/xen-compat.h
index 590de76..dd8a5c0 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -27,7 +27,7 @@
#ifndef __XEN_PUBLIC_XEN_COMPAT_H__
#define __XEN_PUBLIC_XEN_COMPAT_H__
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040700
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040800
#if defined(__XEN__) || defined(__XEN_TOOLS__)
/* Xen is built with matching headers and implements the latest interface. */
diff --git a/xen/include/public/xsm/flask_op.h b/xen/include/public/xsm/flask_op.h
index c76359c..970ec07 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -70,6 +70,7 @@ struct xen_flask_transition {
uint32_t newsid;
};
+#if __XEN_INTERFACE_VERSION__ < 0x00040800
struct xen_flask_userlist {
/* IN: starting SID for list */
uint32_t start_sid;
@@ -83,6 +84,7 @@ struct xen_flask_userlist {
XEN_GUEST_HANDLE(uint32) sids;
} u;
};
+#endif
struct xen_flask_boolean {
/* IN/OUT: numeric identifier for boolean [GET/SET]
@@ -167,7 +169,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 +195,9 @@ struct xen_flask_op {
struct xen_flask_access access;
/* FLASK_CREATE, FLASK_RELABEL, FLASK_MEMBER */
struct xen_flask_transition transition;
+#if __XEN_INTERFACE_VERSION__ < 0x00040800
struct xen_flask_userlist userlist;
+#endif
/* 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 c590440..6a07fc0 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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH 10/17] flask: remove xen_flask_userlist operation
2016-06-20 14:04 ` [PATCH 10/17] flask: remove xen_flask_userlist operation Daniel De Graaf
@ 2016-06-20 14:19 ` Jan Beulich
2016-06-20 14:35 ` Doug Goldstein
1 sibling, 0 replies; 58+ messages in thread
From: Jan Beulich @ 2016-06-20 14:19 UTC (permalink / raw)
To: Daniel De Graaf; +Cc: xen-devel
>>> On 20.06.16 at 16:04, <dgdegra@tycho.nsa.gov> wrote:
> This operation has no known users, and is primarily useful when an MLS
> policy is in use (which has never been shipped with Xen). In addition,
> the information it provides does not actually depend on hypervisor
> state (only on the XSM policy), so an application that needs it could
> compute the results without needing to involve the hypervisor.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Non-flask part
Acked-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 10/17] flask: remove xen_flask_userlist operation
2016-06-20 14:04 ` [PATCH 10/17] flask: remove xen_flask_userlist operation Daniel De Graaf
2016-06-20 14:19 ` Jan Beulich
@ 2016-06-20 14:35 ` Doug Goldstein
2016-06-20 15:07 ` Daniel De Graaf
1 sibling, 1 reply; 58+ messages in thread
From: Doug Goldstein @ 2016-06-20 14:35 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 567 bytes --]
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> This operation has no known users, and is primarily useful when an MLS
> policy is in use (which has never been shipped with Xen). In addition,
> the information it provides does not actually depend on hypervisor
> state (only on the XSM policy), so an application that needs it could
> compute the results without needing to involve the hypervisor.
>
So if I read this language correctly. Removing this does not affect
someone being able to build a MLS policy at a later date right?
--
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 10/17] flask: remove xen_flask_userlist operation
2016-06-20 14:35 ` Doug Goldstein
@ 2016-06-20 15:07 ` Daniel De Graaf
2016-06-20 15:16 ` Doug Goldstein
0 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 15:07 UTC (permalink / raw)
To: Doug Goldstein, xen-devel
On 06/20/2016 10:35 AM, Doug Goldstein wrote:
> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
>> This operation has no known users, and is primarily useful when an MLS
>> policy is in use (which has never been shipped with Xen). In addition,
>> the information it provides does not actually depend on hypervisor
>> state (only on the XSM policy), so an application that needs it could
>> compute the results without needing to involve the hypervisor.
>>
>
> So if I read this language correctly. Removing this does not affect
> someone being able to build a MLS policy at a later date right?
Correct; that support is still there. This hypercall was used to
compute a list of reachable security contexts for a given user, which
is trivial in a non-MLS policy but more complex when one is being
used. This computation makes more sense on Linux (where creating
new contexts via "exec" is common) than on Xen (where normally a
domain cannot create another).
--
Daniel De Graaf
National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 10/17] flask: remove xen_flask_userlist operation
2016-06-20 15:07 ` Daniel De Graaf
@ 2016-06-20 15:16 ` Doug Goldstein
0 siblings, 0 replies; 58+ messages in thread
From: Doug Goldstein @ 2016-06-20 15:16 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 1163 bytes --]
On 6/20/16 10:07 AM, Daniel De Graaf wrote:
> On 06/20/2016 10:35 AM, Doug Goldstein wrote:
>> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
>>> This operation has no known users, and is primarily useful when an MLS
>>> policy is in use (which has never been shipped with Xen). In addition,
>>> the information it provides does not actually depend on hypervisor
>>> state (only on the XSM policy), so an application that needs it could
>>> compute the results without needing to involve the hypervisor.
>>>
>>
>> So if I read this language correctly. Removing this does not affect
>> someone being able to build a MLS policy at a later date right?
>
> Correct; that support is still there. This hypercall was used to
> compute a list of reachable security contexts for a given user, which
> is trivial in a non-MLS policy but more complex when one is being
> used. This computation makes more sense on Linux (where creating
> new contexts via "exec" is common) than on Xen (where normally a
> domain cannot create another).
>
Makes sense. Thanks for clarifying.
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 11/17] flask: improve unknown permission handling
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (9 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 10/17] flask: remove xen_flask_userlist operation Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:37 ` Doug Goldstein
2016-06-20 14:04 ` [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section Daniel De Graaf
` (6 subsequent siblings)
17 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: 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 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.
This patch will allow operations that are not handled by the existing
hooks only if the policy was compiled with "checkpolicy -U allow". In
previous releases, this bit did nothing, and the default remains to deny
the unknown operations.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
xen/xsm/flask/hooks.c | 45 ++++++++++++++++++++++++++--------------
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, 43 insertions(+), 16 deletions(-)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a8d45e7..543406b 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -136,6 +136,24 @@ 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 +289,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 +441,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 +473,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 +539,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 +554,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 +751,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 +826,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 +1143,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 +1416,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 +1447,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 +1551,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 00b5390..3a12d96 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 f158ce3..238a042 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 6a07fc0..86f94c9 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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH 11/17] flask: improve unknown permission handling
2016-06-20 14:04 ` [PATCH 11/17] flask: improve unknown permission handling Daniel De Graaf
@ 2016-06-20 14:37 ` Doug Goldstein
0 siblings, 0 replies; 58+ messages in thread
From: Doug Goldstein @ 2016-06-20 14:37 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 923 bytes --]
On 6/20/16 9:04 AM, 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 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.
>
> This patch will allow operations that are not handled by the existing
> hooks only if the policy was compiled with "checkpolicy -U allow". In
> previous releases, this bit did nothing, and the default remains to deny
> the unknown operations.
>
> 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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (10 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 11/17] flask: improve unknown permission handling Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:38 ` Doug Goldstein
2016-06-21 15:21 ` Andrew Cooper
2016-06-20 14:04 ` [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig Daniel De Graaf
` (5 subsequent siblings)
17 siblings, 2 replies; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: 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/include/xsm/xsm.h | 16 ++++++++--------
xen/xsm/flask/hooks.c | 4 +---
xen/xsm/xsm_core.c | 13 +------------
5 files changed, 10 insertions(+), 33 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/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 543406b..d632b0e 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1817,7 +1817,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;
@@ -1860,8 +1860,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..3487742 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -36,17 +36,6 @@ static inline int verify(struct xsm_operations *ops)
return 0;
}
-static void __init do_xsm_initcalls(void)
-{
- xsm_initcall_t *call;
- call = __xsm_initcall_start;
- while ( call < __xsm_initcall_end )
- {
- (*call) ();
- call++;
- }
-}
-
static int __init xsm_core_init(void)
{
if ( verify(&dummy_xsm_ops) )
@@ -57,7 +46,7 @@ static int __init xsm_core_init(void)
}
xsm_ops = &dummy_xsm_ops;
- do_xsm_initcalls();
+ flask_init();
return 0;
}
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section
2016-06-20 14:04 ` [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section Daniel De Graaf
@ 2016-06-20 14:38 ` Doug Goldstein
2016-06-21 15:21 ` Andrew Cooper
1 sibling, 0 replies; 58+ messages in thread
From: Doug Goldstein @ 2016-06-20 14:38 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 529 bytes --]
On 6/20/16 9:04 AM, 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: 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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section
2016-06-20 14:04 ` [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section Daniel De Graaf
2016-06-20 14:38 ` Doug Goldstein
@ 2016-06-21 15:21 ` Andrew Cooper
2016-06-21 15:41 ` Julien Grall
1 sibling, 1 reply; 58+ messages in thread
From: Andrew Cooper @ 2016-06-21 15:21 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel; +Cc: Julien Grall, Stefano Stabellini
On 20/06/16 15:04, 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>
(CC'ing ARM maintainers)
> ---
> xen/arch/arm/xen.lds.S | 5 -----
> xen/arch/x86/xen.lds.S | 5 -----
> xen/include/xsm/xsm.h | 16 ++++++++--------
> xen/xsm/flask/hooks.c | 4 +---
> xen/xsm/xsm_core.c | 13 +------------
> 5 files changed, 10 insertions(+), 33 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/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 543406b..d632b0e 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1817,7 +1817,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;
>
> @@ -1860,8 +1860,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..3487742 100644
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -36,17 +36,6 @@ static inline int verify(struct xsm_operations *ops)
> return 0;
> }
>
> -static void __init do_xsm_initcalls(void)
> -{
> - xsm_initcall_t *call;
> - call = __xsm_initcall_start;
> - while ( call < __xsm_initcall_end )
> - {
> - (*call) ();
> - call++;
> - }
> -}
> -
> static int __init xsm_core_init(void)
> {
> if ( verify(&dummy_xsm_ops) )
> @@ -57,7 +46,7 @@ static int __init xsm_core_init(void)
> }
>
> xsm_ops = &dummy_xsm_ops;
> - do_xsm_initcalls();
> + flask_init();
>
> return 0;
> }
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section
2016-06-21 15:21 ` Andrew Cooper
@ 2016-06-21 15:41 ` Julien Grall
2016-06-21 16:03 ` Andrew Cooper
0 siblings, 1 reply; 58+ messages in thread
From: Julien Grall @ 2016-06-21 15:41 UTC (permalink / raw)
To: Andrew Cooper, Daniel De Graaf, xen-devel; +Cc: Stefano Stabellini
Hello,
On 21/06/16 16:21, Andrew Cooper wrote:
> On 20/06/16 15:04, 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>
>
> (CC'ing ARM maintainers)
For the ARM bits:
Acked-by: Julien Grall <julien.grall@arm.com>
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section
2016-06-21 15:41 ` Julien Grall
@ 2016-06-21 16:03 ` Andrew Cooper
0 siblings, 0 replies; 58+ messages in thread
From: Andrew Cooper @ 2016-06-21 16:03 UTC (permalink / raw)
To: Julien Grall, Daniel De Graaf, xen-devel; +Cc: Stefano Stabellini
On 21/06/16 16:41, Julien Grall wrote:
> Hello,
>
> On 21/06/16 16:21, Andrew Cooper wrote:
>> On 20/06/16 15:04, 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>
>>
>> (CC'ing ARM maintainers)
>
> For the ARM bits:
>
> Acked-by: Julien Grall <julien.grall@arm.com>
And committed (as this patch unblocks one of my series).
I will leave the remainder of the series until a decision is taken about
patch 13.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (11 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:41 ` Doug Goldstein
` (2 more replies)
2016-06-20 14:04 ` [PATCH 14/17] xsm: annotate setup functions with __init Daniel De Graaf
` (4 subsequent siblings)
17 siblings, 3 replies; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf
Since enabling XSM is required to enable FLASK, place the option for
FLASK below the one for XSM. In addition, since it does not make sense
to enable XSM without any XSM providers, and FLASK is the only XSM
provider, hide the option to disable FLASK under EXPERT.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
xen/common/Kconfig | 37 +++++++++++++++++++------------------
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index cd59574..6a51fd5 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
+ def_bool y
+ bool "FLux Advanced Security Kernel support" if EXPERT = "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"
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig
2016-06-20 14:04 ` [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig Daniel De Graaf
@ 2016-06-20 14:41 ` Doug Goldstein
2016-06-20 14:42 ` Doug Goldstein
2016-06-20 14:46 ` Doug Goldstein
2016-06-21 17:09 ` [PATCH 13/17 v3] " Daniel De Graaf
2 siblings, 1 reply; 58+ messages in thread
From: Doug Goldstein @ 2016-06-20 14:41 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 1354 bytes --]
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> Since enabling XSM is required to enable FLASK, place the option for
> FLASK below the one for XSM. In addition, since it does not make sense
> to enable XSM without any XSM providers, and FLASK is the only XSM
> provider, hide the option to disable FLASK under EXPERT.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
> xen/common/Kconfig | 37 +++++++++++++++++++------------------
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index cd59574..6a51fd5 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.
> -
<snip>
>
> +config FLASK
> + def_bool y
> + bool "FLux Advanced Security Kernel support" if EXPERT = "y"
Why did FLASK become dependent on EXPERT? It wasn't previously.
--
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig
2016-06-20 14:41 ` Doug Goldstein
@ 2016-06-20 14:42 ` Doug Goldstein
0 siblings, 0 replies; 58+ messages in thread
From: Doug Goldstein @ 2016-06-20 14:42 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 1505 bytes --]
On 6/20/16 9:41 AM, Doug Goldstein wrote:
> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
>> Since enabling XSM is required to enable FLASK, place the option for
>> FLASK below the one for XSM. In addition, since it does not make sense
>> to enable XSM without any XSM providers, and FLASK is the only XSM
>> provider, hide the option to disable FLASK under EXPERT.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>> xen/common/Kconfig | 37 +++++++++++++++++++------------------
>> 1 file changed, 19 insertions(+), 18 deletions(-)
>>
>> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
>> index cd59574..6a51fd5 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.
>> -
>
> <snip>
>
>>
>> +config FLASK
>> + def_bool y
>> + bool "FLux Advanced Security Kernel support" if EXPERT = "y"
>
> Why did FLASK become dependent on EXPERT? It wasn't previously.
>
Gah. Helps to read the commit message. Ignore the noise.
--
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig
2016-06-20 14:04 ` [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig Daniel De Graaf
2016-06-20 14:41 ` Doug Goldstein
@ 2016-06-20 14:46 ` Doug Goldstein
2016-06-20 15:11 ` Daniel De Graaf
2016-06-21 17:09 ` [PATCH 13/17 v3] " Daniel De Graaf
2 siblings, 1 reply; 58+ messages in thread
From: Doug Goldstein @ 2016-06-20 14:46 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 804 bytes --]
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> Since enabling XSM is required to enable FLASK, place the option for
> FLASK below the one for XSM. In addition, since it does not make sense
> to enable XSM without any XSM providers, and FLASK is the only XSM
> provider, hide the option to disable FLASK under EXPERT.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
> @@ -137,6 +119,25 @@ config XSM
>
> If unsure, say N.
>
> +config FLASK
> + def_bool y
> + bool "FLux Advanced Security Kernel support" if EXPERT = "y"
Ok. Here's the real review. I think you want the prompt to be optional
if EXPERT is enabled then I think you need to use "prompt" instead of
"bool". You've already got this set to a bool with the "def_bool" line.
--
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig
2016-06-20 14:46 ` Doug Goldstein
@ 2016-06-20 15:11 ` Daniel De Graaf
2016-06-20 15:28 ` Jan Beulich
0 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 15:11 UTC (permalink / raw)
To: Doug Goldstein, xen-devel
On 06/20/2016 10:46 AM, Doug Goldstein wrote:
> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
>> Since enabling XSM is required to enable FLASK, place the option for
>> FLASK below the one for XSM. In addition, since it does not make sense
>> to enable XSM without any XSM providers, and FLASK is the only XSM
>> provider, hide the option to disable FLASK under EXPERT.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>
>> @@ -137,6 +119,25 @@ config XSM
>>
>> If unsure, say N.
>>
>> +config FLASK
>> + def_bool y
>> + bool "FLux Advanced Security Kernel support" if EXPERT = "y"
>
> Ok. Here's the real review. I think you want the prompt to be optional
> if EXPERT is enabled then I think you need to use "prompt" instead of
> "bool". You've already got this set to a bool with the "def_bool" line.
OK. This version also apparently works, since I tested it, but if
prompt is the preferred keyword I'll change it.
--
Daniel De Graaf
National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig
2016-06-20 15:11 ` Daniel De Graaf
@ 2016-06-20 15:28 ` Jan Beulich
2016-06-20 16:49 ` Doug Goldstein
0 siblings, 1 reply; 58+ messages in thread
From: Jan Beulich @ 2016-06-20 15:28 UTC (permalink / raw)
To: Doug Goldstein, Daniel De Graaf; +Cc: xen-devel
>>> On 20.06.16 at 17:11, <dgdegra@tycho.nsa.gov> wrote:
> On 06/20/2016 10:46 AM, Doug Goldstein wrote:
>> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
>>> Since enabling XSM is required to enable FLASK, place the option for
>>> FLASK below the one for XSM. In addition, since it does not make sense
>>> to enable XSM without any XSM providers, and FLASK is the only XSM
>>> provider, hide the option to disable FLASK under EXPERT.
>>>
>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>> ---
>>
>>> @@ -137,6 +119,25 @@ config XSM
>>>
>>> If unsure, say N.
>>>
>>> +config FLASK
>>> + def_bool y
>>> + bool "FLux Advanced Security Kernel support" if EXPERT = "y"
>>
>> Ok. Here's the real review. I think you want the prompt to be optional
>> if EXPERT is enabled then I think you need to use "prompt" instead of
>> "bool". You've already got this set to a bool with the "def_bool" line.
>
> OK. This version also apparently works, since I tested it, but if
> prompt is the preferred keyword I'll change it.
Yeah, the bool is redundant here. It should be either a
def_bool/prompt pair, or a bool/default one. Personally I'd prefer
the latter, but since Doug asked for the former that's fine too.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig
2016-06-20 15:28 ` Jan Beulich
@ 2016-06-20 16:49 ` Doug Goldstein
0 siblings, 0 replies; 58+ messages in thread
From: Doug Goldstein @ 2016-06-20 16:49 UTC (permalink / raw)
To: Jan Beulich, Daniel De Graaf; +Cc: xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 1386 bytes --]
On 6/20/16 10:28 AM, Jan Beulich wrote:
>>>> On 20.06.16 at 17:11, <dgdegra@tycho.nsa.gov> wrote:
>> On 06/20/2016 10:46 AM, Doug Goldstein wrote:
>>> On 6/20/16 9:04 AM, Daniel De Graaf wrote:
>>>> Since enabling XSM is required to enable FLASK, place the option for
>>>> FLASK below the one for XSM. In addition, since it does not make sense
>>>> to enable XSM without any XSM providers, and FLASK is the only XSM
>>>> provider, hide the option to disable FLASK under EXPERT.
>>>>
>>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>> ---
>>>
>>>> @@ -137,6 +119,25 @@ config XSM
>>>>
>>>> If unsure, say N.
>>>>
>>>> +config FLASK
>>>> + def_bool y
>>>> + bool "FLux Advanced Security Kernel support" if EXPERT = "y"
>>>
>>> Ok. Here's the real review. I think you want the prompt to be optional
>>> if EXPERT is enabled then I think you need to use "prompt" instead of
>>> "bool". You've already got this set to a bool with the "def_bool" line.
>>
>> OK. This version also apparently works, since I tested it, but if
>> prompt is the preferred keyword I'll change it.
>
> Yeah, the bool is redundant here. It should be either a
> def_bool/prompt pair, or a bool/default one. Personally I'd prefer
> the latter, but since Doug asked for the former that's fine too.
>
> Jan
>
I'm honestly in different.
--
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 13/17 v3] xen: move FLASK entry under XSM in Kconfig
2016-06-20 14:04 ` [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig Daniel De Graaf
2016-06-20 14:41 ` Doug Goldstein
2016-06-20 14:46 ` Doug Goldstein
@ 2016-06-21 17:09 ` Daniel De Graaf
2016-06-24 14:43 ` Doug Goldstein
2 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-21 17:09 UTC (permalink / raw)
To: xen-devel; +Cc: andrew.cooper3, Daniel De Graaf, JBeulich
Since enabling XSM is required to enable FLASK, place the option for
FLASK below the one for XSM. In addition, since it does not make sense
to enable XSM without any XSM providers, and FLASK is the only XSM
provider, hide the option to disable FLASK under EXPERT.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
Changes from v2: use def_bool/prompt instead of def_bool/bool so that it
matches the other "if EXPERT" items in this file
xen/common/Kconfig | 37 +++++++++++++++++++------------------
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index cd59574..faee3ec 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
+ def_bool y
+ prompt "FLux Advanced Security Kernel support" if EXPERT = "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"
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread
* Re: [PATCH 13/17 v3] xen: move FLASK entry under XSM in Kconfig
2016-06-21 17:09 ` [PATCH 13/17 v3] " Daniel De Graaf
@ 2016-06-24 14:43 ` Doug Goldstein
0 siblings, 0 replies; 58+ messages in thread
From: Doug Goldstein @ 2016-06-24 14:43 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel; +Cc: andrew.cooper3, JBeulich
[-- Attachment #1.1.1: Type: text/plain, Size: 493 bytes --]
On 6/21/16 12:09 PM, Daniel De Graaf wrote:
> Since enabling XSM is required to enable FLASK, place the option for
> FLASK below the one for XSM. In addition, since it does not make sense
> to enable XSM without any XSM providers, and FLASK is the only XSM
> provider, hide the option to disable FLASK under EXPERT.
>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Thanks for the update Daniel.
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 14/17] xsm: annotate setup functions with __init
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (12 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 13/17] xen: move FLASK entry under XSM in Kconfig Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:46 ` Doug Goldstein
2016-06-20 14:04 ` [PATCH 15/17] xsm: clean up unregistration Daniel De Graaf
` (3 subsequent siblings)
17 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf
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/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 3487742..78d881b 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -127,7 +127,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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH 15/17] xsm: clean up unregistration
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (13 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 14/17] xsm: annotate setup functions with __init Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:47 ` Doug Goldstein
2016-06-20 14:04 ` [PATCH 16/17] xen: Make FLASK_AVC_STATS kconfig option visible Daniel De Graaf
` (2 subsequent siblings)
17 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: 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>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
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 d632b0e..2692a6f 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;
@@ -1842,7 +1840,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 78d881b..8df1a3c 100644
--- a/xen/xsm/xsm_core.c
+++ b/xen/xsm/xsm_core.c
@@ -144,22 +144,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.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH 16/17] xen: Make FLASK_AVC_STATS kconfig option visible
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (14 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 15/17] xsm: clean up unregistration Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:49 ` Doug Goldstein
2016-06-20 14:04 ` [PATCH 17/17] xsm: add a default policy to .init.data Daniel De Graaf
2016-06-21 15:24 ` [PATCH v2 00/17] XSM/FLASK updates for 4.8 Andrew Cooper
17 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: Daniel De Graaf
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
xen/common/Kconfig | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 6a51fd5..8fb5a68 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -134,9 +134,14 @@ config FLASK
config FLASK_AVC_STATS
def_bool y
+ prompt "Maintain statistics on the FLASK access vector cache" if EXPERT = "y"
depends on FLASK
---help---
- Maintain statistics on the access vector cache
+ Maintain counters on the access vector cache that can be viewed using
+ the FLASK_AVC_CACHESTATS sub-op of the xsm_op hypercall. Disabling
+ this will save a tiny amount of memory and time to update the stats.
+
+ If unsure, say Y.
# Enable schedulers
menu "Schedulers"
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH 16/17] xen: Make FLASK_AVC_STATS kconfig option visible
2016-06-20 14:04 ` [PATCH 16/17] xen: Make FLASK_AVC_STATS kconfig option visible Daniel De Graaf
@ 2016-06-20 14:49 ` Doug Goldstein
0 siblings, 0 replies; 58+ messages in thread
From: Doug Goldstein @ 2016-06-20 14:49 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 652 bytes --]
On 6/20/16 9:04 AM, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Doug Goldstein <cardoe@cardoe.com>
> ---
> xen/common/Kconfig | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index 6a51fd5..8fb5a68 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -134,9 +134,14 @@ config FLASK
>
> config FLASK_AVC_STATS
> def_bool y
> + prompt "Maintain statistics on the FLASK access vector cache" if EXPERT = "y"
This is what I was thinking you need to do for patch 13.
--
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (15 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 16/17] xen: Make FLASK_AVC_STATS kconfig option visible Daniel De Graaf
@ 2016-06-20 14:04 ` Daniel De Graaf
2016-06-20 14:52 ` Doug Goldstein
2016-06-24 16:30 ` Julien Grall
2016-06-21 15:24 ` [PATCH v2 00/17] XSM/FLASK updates for 4.8 Andrew Cooper
17 siblings, 2 replies; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-20 14:04 UTC (permalink / raw)
To: xen-devel; +Cc: 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>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
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 | 15 ++++++++++++++-
7 files changed, 81 insertions(+), 23 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 8fb5a68..6e2a583 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -143,6 +143,23 @@ config FLASK_AVC_STATS
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.
+
# Enable schedulers
menu "Schedulers"
visible if EXPERT = "y"
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 8df1a3c..509210c 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 int __init xsm_core_init(void)
{
if ( verify(&dummy_xsm_ops) )
@@ -46,6 +57,7 @@ static int __init xsm_core_init(void)
}
xsm_ops = &dummy_xsm_ops;
+ xsm_policy_init();
flask_init();
return 0;
@@ -98,7 +110,8 @@ int __init xsm_dt_init(void)
ret = xsm_core_init();
- xfree(policy_buffer);
+ if ( policy_buffer != __xsm_init_policy_start )
+ xfree(policy_buffer);
return ret;
}
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-20 14:04 ` [PATCH 17/17] xsm: add a default policy to .init.data Daniel De Graaf
@ 2016-06-20 14:52 ` Doug Goldstein
2016-06-24 16:30 ` Julien Grall
1 sibling, 0 replies; 58+ messages in thread
From: Doug Goldstein @ 2016-06-20 14:52 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel
[-- Attachment #1.1.1: Type: text/plain, Size: 848 bytes --]
On 6/20/16 9:04 AM, 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>
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-20 14:04 ` [PATCH 17/17] xsm: add a default policy to .init.data Daniel De Graaf
2016-06-20 14:52 ` Doug Goldstein
@ 2016-06-24 16:30 ` Julien Grall
2016-06-24 16:50 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 58+ messages in thread
From: Julien Grall @ 2016-06-24 16:30 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel, Stefano Stabellini
Cc: Andrew Cooper, Wei Liu, George Dunlap, Jan Beulich
Hello Daniel,
Please try to CC relevant maintainers on your patch. I would have missed
it if Andrew did not ping me on IRC.
On 20/06/16 15:04, 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>
For ARM bits:
Acked-by: Julien Grall <julien.grall@arm.com>
Although, I one a question below.
[...]
> 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
I would have expect a warning (if not an error) here to tell the user
that checkpolicy is not available. Otherwise it may take some time to
the user to understand why the policy is not loaded/present. Because if
you enable XSM, you don't necessarily check which other options have
been enabled by default.
> +endif
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-24 16:30 ` Julien Grall
@ 2016-06-24 16:50 ` Konrad Rzeszutek Wilk
2016-06-24 17:34 ` Daniel De Graaf
0 siblings, 1 reply; 58+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-06-24 16:50 UTC (permalink / raw)
To: Julien Grall
Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, George Dunlap,
xen-devel, Jan Beulich, Daniel De Graaf
On Fri, Jun 24, 2016 at 05:30:32PM +0100, Julien Grall wrote:
> Hello Daniel,
>
> Please try to CC relevant maintainers on your patch. I would have missed it
> if Andrew did not ping me on IRC.
>
> On 20/06/16 15:04, 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>
>
> For ARM bits:
>
> Acked-by: Julien Grall <julien.grall@arm.com>
>
> Although, I one a question below.
>
> [...]
>
> >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
>
> I would have expect a warning (if not an error) here to tell the user that
> checkpolicy is not available. Otherwise it may take some time to the user to
> understand why the policy is not loaded/present. Because if you enable XSM,
> you don't necessarily check which other options have been enabled by
> default.
Good point! And we should probably update the INSTALL document too to mention
that you need checkpoint tool!
>
> >+endif
>
> Regards,
>
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-24 16:50 ` Konrad Rzeszutek Wilk
@ 2016-06-24 17:34 ` Daniel De Graaf
2016-06-24 17:40 ` Konrad Rzeszutek Wilk
` (2 more replies)
0 siblings, 3 replies; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-24 17:34 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Julien Grall
Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, George Dunlap,
xen-devel, Jan Beulich
On 06/24/2016 12:50 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 24, 2016 at 05:30:32PM +0100, Julien Grall wrote:
>> Hello Daniel,
>>
>> Please try to CC relevant maintainers on your patch. I would have missed it
>> if Andrew did not ping me on IRC.
>>
>> On 20/06/16 15:04, 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>
>>
>> For ARM bits:
>>
>> Acked-by: Julien Grall <julien.grall@arm.com>
>>
>> Although, I one a question below.
>>
>> [...]
>>
>>> 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
>>
>> I would have expect a warning (if not an error) here to tell the user that
>> checkpolicy is not available. Otherwise it may take some time to the user to
>> understand why the policy is not loaded/present. Because if you enable XSM,
>> you don't necessarily check which other options have been enabled by
>> default.
>
> Good point! And we should probably update the INSTALL document too to mention
> that you need checkpoint tool!
The dependency on checkpolicy is called out in the Kconfig item that
enables this option. Are you suggesting I should add a mention below
the instructions on running menuconfig for XSM in INSTALL?
I can remove the HAS_CHECKPOLICY check completely and make the call to
checkpolicy only conditional on the Kconfig option. I think this is
less complicated than stopping the compile one step above the invocation
of checkpolicy, and probably just as informative (and better, if the
detection heuristic ever breaks).
>>
>>> +endif
>>
>> Regards,
>>
>> --
>> Julien Grall
>
--
Daniel De Graaf
National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-24 17:34 ` Daniel De Graaf
@ 2016-06-24 17:40 ` Konrad Rzeszutek Wilk
2016-06-24 17:42 ` Daniel De Graaf
2016-06-24 17:41 ` Konrad Rzeszutek Wilk
2016-06-24 17:44 ` Julien Grall
2 siblings, 1 reply; 58+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-06-24 17:40 UTC (permalink / raw)
To: Daniel De Graaf
Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, George Dunlap,
xen-devel, Julien Grall, Jan Beulich
On Fri, Jun 24, 2016 at 01:34:29PM -0400, Daniel De Graaf wrote:
> On 06/24/2016 12:50 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Jun 24, 2016 at 05:30:32PM +0100, Julien Grall wrote:
> >>Hello Daniel,
> >>
> >>Please try to CC relevant maintainers on your patch. I would have missed it
> >>if Andrew did not ping me on IRC.
> >>
> >>On 20/06/16 15:04, 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>
> >>
> >>For ARM bits:
> >>
> >>Acked-by: Julien Grall <julien.grall@arm.com>
> >>
> >>Although, I one a question below.
> >>
> >>[...]
> >>
> >>>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
> >>
> >>I would have expect a warning (if not an error) here to tell the user that
> >>checkpolicy is not available. Otherwise it may take some time to the user to
> >>understand why the policy is not loaded/present. Because if you enable XSM,
> >>you don't necessarily check which other options have been enabled by
> >>default.
> >
> >Good point! And we should probably update the INSTALL document too to mention
> >that you need checkpoint tool!
>
> The dependency on checkpolicy is called out in the Kconfig item that
> enables this option. Are you suggesting I should add a mention below
> the instructions on running menuconfig for XSM in INSTALL?
No, I just thinking that the INSTALL has a list of packages one needs.
And it may be good to have checkpolicy on it.
>
> I can remove the HAS_CHECKPOLICY check completely and make the call to
> checkpolicy only conditional on the Kconfig option. I think this is
> less complicated than stopping the compile one step above the invocation
> of checkpolicy, and probably just as informative (and better, if the
> detection heuristic ever breaks).
I actually like the way you have it - with the checkpolicy check determining
whether the Kconfig option for XSM is shown or not.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-24 17:40 ` Konrad Rzeszutek Wilk
@ 2016-06-24 17:42 ` Daniel De Graaf
2016-06-24 17:46 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-24 17:42 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, George Dunlap,
xen-devel, Julien Grall, Jan Beulich
On 06/24/2016 01:40 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 24, 2016 at 01:34:29PM -0400, Daniel De Graaf wrote:
>> On 06/24/2016 12:50 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Jun 24, 2016 at 05:30:32PM +0100, Julien Grall wrote:
>>>> Hello Daniel,
>>>>
>>>> Please try to CC relevant maintainers on your patch. I would have missed it
>>>> if Andrew did not ping me on IRC.
>>>>
>>>> On 20/06/16 15:04, 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>
>>>>
>>>> For ARM bits:
>>>>
>>>> Acked-by: Julien Grall <julien.grall@arm.com>
>>>>
>>>> Although, I one a question below.
>>>>
>>>> [...]
>>>>
>>>>> 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
>>>>
>>>> I would have expect a warning (if not an error) here to tell the user that
>>>> checkpolicy is not available. Otherwise it may take some time to the user to
>>>> understand why the policy is not loaded/present. Because if you enable XSM,
>>>> you don't necessarily check which other options have been enabled by
>>>> default.
>>>
>>> Good point! And we should probably update the INSTALL document too to mention
>>> that you need checkpoint tool!
>>
>> The dependency on checkpolicy is called out in the Kconfig item that
>> enables this option. Are you suggesting I should add a mention below
>> the instructions on running menuconfig for XSM in INSTALL?
>
> No, I just thinking that the INSTALL has a list of packages one needs.
> And it may be good to have checkpolicy on it.
>
>>
>> I can remove the HAS_CHECKPOLICY check completely and make the call to
>> checkpolicy only conditional on the Kconfig option. I think this is
>> less complicated than stopping the compile one step above the invocation
>> of checkpolicy, and probably just as informative (and better, if the
>> detection heuristic ever breaks).
>
> I actually like the way you have it - with the checkpolicy check determining
> whether the Kconfig option for XSM is shown or not.
Is that possible? That's not what I have; the check I have only determines
if the Kconfig option does anything or not, it is still visible regardless.
--
Daniel De Graaf
National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-24 17:42 ` Daniel De Graaf
@ 2016-06-24 17:46 ` Konrad Rzeszutek Wilk
2016-06-24 18:02 ` Daniel De Graaf
0 siblings, 1 reply; 58+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-06-24 17:46 UTC (permalink / raw)
To: Daniel De Graaf
Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, George Dunlap,
xen-devel, Julien Grall, Jan Beulich
> >>I can remove the HAS_CHECKPOLICY check completely and make the call to
> >>checkpolicy only conditional on the Kconfig option. I think this is
> >>less complicated than stopping the compile one step above the invocation
> >>of checkpolicy, and probably just as informative (and better, if the
> >>detection heuristic ever breaks).
> >
> >I actually like the way you have it - with the checkpolicy check determining
> >whether the Kconfig option for XSM is shown or not.
>
> Is that possible? That's not what I have; the check I have only determines
> if the Kconfig option does anything or not, it is still visible regardless.
Totally!
See 95111a94f0168699d5154c7a25bd33865559e2c xsplice: Stacking build-id dependency checking.
Thanks.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-24 17:46 ` Konrad Rzeszutek Wilk
@ 2016-06-24 18:02 ` Daniel De Graaf
2016-06-24 18:36 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 58+ messages in thread
From: Daniel De Graaf @ 2016-06-24 18:02 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, George Dunlap,
xen-devel, Julien Grall, Jan Beulich
On 06/24/2016 01:46 PM, Konrad Rzeszutek Wilk wrote:
>>>> I can remove the HAS_CHECKPOLICY check completely and make the call to
>>>> checkpolicy only conditional on the Kconfig option. I think this is
>>>> less complicated than stopping the compile one step above the invocation
>>>> of checkpolicy, and probably just as informative (and better, if the
>>>> detection heuristic ever breaks).
>>>
>>> I actually like the way you have it - with the checkpolicy check determining
>>> whether the Kconfig option for XSM is shown or not.
>>
>> Is that possible? That's not what I have; the check I have only determines
>> if the Kconfig option does anything or not, it is still visible regardless.
>
> Totally!
>
> See 95111a94f0168699d5154c7a25bd33865559e2c xsplice: Stacking build-id dependency checking.
>
> Thanks.
Ah, I hadn't considered setting the variable in the top-level Config.mk.
If I were to add the HAS_CHECKPOLICY check there, I think it would make
sense to have it adjust the default value of CONFIG_XSM_POLICY, but
not hide the option. If someone deliberately enables the option, then
having the compile error show up is less confusing than the current
method where it gets enabled when only selecting XSM.
Anyway, since checkpolicy is required to make use of FLASK, anyone who
currently enables XSM is going to need to install it at some point: either
in the hypervisor compile for the built-in policy or the tools compile for
the bootloader- or dom0-provided policy. Having the error show up sooner
is not all that much of a problem. This would change if XSM were to be
enabled by default, because I would then expect "xsm enabled, flask disabled"
to become a more common case - and that does not require a policy.
--
Daniel De Graaf
National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-24 18:02 ` Daniel De Graaf
@ 2016-06-24 18:36 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 58+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-06-24 18:36 UTC (permalink / raw)
To: Daniel De Graaf
Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, George Dunlap,
xen-devel, Julien Grall, Jan Beulich
On Fri, Jun 24, 2016 at 02:02:42PM -0400, Daniel De Graaf wrote:
> On 06/24/2016 01:46 PM, Konrad Rzeszutek Wilk wrote:
> >>>>I can remove the HAS_CHECKPOLICY check completely and make the call to
> >>>>checkpolicy only conditional on the Kconfig option. I think this is
> >>>>less complicated than stopping the compile one step above the invocation
> >>>>of checkpolicy, and probably just as informative (and better, if the
> >>>>detection heuristic ever breaks).
> >>>
> >>>I actually like the way you have it - with the checkpolicy check determining
> >>>whether the Kconfig option for XSM is shown or not.
> >>
> >>Is that possible? That's not what I have; the check I have only determines
> >>if the Kconfig option does anything or not, it is still visible regardless.
> >
> >Totally!
> >
> >See 95111a94f0168699d5154c7a25bd33865559e2c xsplice: Stacking build-id dependency checking.
> >
> >Thanks.
>
> Ah, I hadn't considered setting the variable in the top-level Config.mk.
> If I were to add the HAS_CHECKPOLICY check there, I think it would make
> sense to have it adjust the default value of CONFIG_XSM_POLICY, but
> not hide the option. If someone deliberately enables the option, then
> having the compile error show up is less confusing than the current
> method where it gets enabled when only selecting XSM.
Ah, that would work too and I believe satisfy Julien as well!
>
> Anyway, since checkpolicy is required to make use of FLASK, anyone who
> currently enables XSM is going to need to install it at some point: either
> in the hypervisor compile for the built-in policy or the tools compile for
> the bootloader- or dom0-provided policy. Having the error show up sooner
> is not all that much of a problem. This would change if XSM were to be
> enabled by default, because I would then expect "xsm enabled, flask disabled"
> to become a more common case - and that does not require a policy.
/me nods.
>
> --
> Daniel De Graaf
> National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-24 17:34 ` Daniel De Graaf
2016-06-24 17:40 ` Konrad Rzeszutek Wilk
@ 2016-06-24 17:41 ` Konrad Rzeszutek Wilk
2016-06-24 17:47 ` Julien Grall
2016-06-24 17:44 ` Julien Grall
2 siblings, 1 reply; 58+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-06-24 17:41 UTC (permalink / raw)
To: Daniel De Graaf
Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, George Dunlap,
xen-devel, Julien Grall, Jan Beulich
On Fri, Jun 24, 2016 at 01:34:29PM -0400, Daniel De Graaf wrote:
> On 06/24/2016 12:50 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Jun 24, 2016 at 05:30:32PM +0100, Julien Grall wrote:
> >>Hello Daniel,
> >>
> >>Please try to CC relevant maintainers on your patch. I would have missed it
> >>if Andrew did not ping me on IRC.
> >>
> >>On 20/06/16 15:04, 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>
> >>
> >>For ARM bits:
> >>
> >>Acked-by: Julien Grall <julien.grall@arm.com>
> >>
> >>Although, I one a question below.
> >>
> >>[...]
> >>
> >>>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
> >>
> >>I would have expect a warning (if not an error) here to tell the user that
> >>checkpolicy is not available. Otherwise it may take some time to the user to
> >>understand why the policy is not loaded/present. Because if you enable XSM,
> >>you don't necessarily check which other options have been enabled by
> >>default.
You won't be able to enable XSM if checkpolicy is not present.
As in, it won't show up as an option in the oldconfig or menuconfig at all.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-24 17:41 ` Konrad Rzeszutek Wilk
@ 2016-06-24 17:47 ` Julien Grall
0 siblings, 0 replies; 58+ messages in thread
From: Julien Grall @ 2016-06-24 17:47 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Daniel De Graaf
Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, George Dunlap,
xen-devel, Jan Beulich
Hello Konrad,
On 24/06/16 18:41, Konrad Rzeszutek Wilk wrote:
> On Fri, Jun 24, 2016 at 01:34:29PM -0400, Daniel De Graaf wrote:
>> On 06/24/2016 12:50 PM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Jun 24, 2016 at 05:30:32PM +0100, Julien Grall wrote:
>>>> I would have expect a warning (if not an error) here to tell the user that
>>>> checkpolicy is not available. Otherwise it may take some time to the user to
>>>> understand why the policy is not loaded/present. Because if you enable XSM,
>>>> you don't necessarily check which other options have been enabled by
>>>> default.
>
> You won't be able to enable XSM if checkpolicy is not present.
> As in, it won't show up as an option in the oldconfig or menuconfig at all.
Really? I don't have checkpolicy on my platform and XSM is still present
in the menuconfig.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH 17/17] xsm: add a default policy to .init.data
2016-06-24 17:34 ` Daniel De Graaf
2016-06-24 17:40 ` Konrad Rzeszutek Wilk
2016-06-24 17:41 ` Konrad Rzeszutek Wilk
@ 2016-06-24 17:44 ` Julien Grall
2 siblings, 0 replies; 58+ messages in thread
From: Julien Grall @ 2016-06-24 17:44 UTC (permalink / raw)
To: Daniel De Graaf, Konrad Rzeszutek Wilk
Cc: Stefano Stabellini, Wei Liu, Andrew Cooper, George Dunlap,
xen-devel, Jan Beulich
Hi Daniel,
On 24/06/16 18:34, Daniel De Graaf wrote:
> On 06/24/2016 12:50 PM, Konrad Rzeszutek Wilk wrote:
>> On Fri, Jun 24, 2016 at 05:30:32PM +0100, Julien Grall wrote:
>>>> 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
>>>
>>> I would have expect a warning (if not an error) here to tell the user
>>> that
>>> checkpolicy is not available. Otherwise it may take some time to the
>>> user to
>>> understand why the policy is not loaded/present. Because if you
>>> enable XSM,
>>> you don't necessarily check which other options have been enabled by
>>> default.
>>
>> Good point! And we should probably update the INSTALL document too to
>> mention
>> that you need checkpoint tool!
>
> The dependency on checkpolicy is called out in the Kconfig item that
> enables this option.
AFAICT, the dependency is only called out for CONFIG_XSM_POLICY.
However, this option is enabled by default if CONFIG_XSM is selected.
User may not read what was enabled by default because of CONFIG_XSM
selected.
In any case, silently disable an option is a bad idea and will likely
cause trouble in the future if we ever decide to enable XSM by default.
Another use case would be, a user post his .config on the ML asking why
the policy is not loaded.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v2 00/17] XSM/FLASK updates for 4.8
2016-06-20 14:04 [PATCH v2 00/17] XSM/FLASK updates for 4.8 Daniel De Graaf
` (16 preceding siblings ...)
2016-06-20 14:04 ` [PATCH 17/17] xsm: add a default policy to .init.data Daniel De Graaf
@ 2016-06-21 15:24 ` Andrew Cooper
2016-06-27 9:48 ` Andrew Cooper
17 siblings, 1 reply; 58+ messages in thread
From: Andrew Cooper @ 2016-06-21 15:24 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel
On 20/06/16 15:04, Daniel De Graaf wrote:
> Changes from v1:
> - Change c->context and c->sid from arrays to fields when shrinking
> - Keep struct xen_flask_userlist in headers, but guard it with #ifs
> - Split off Kconfig changes into their own patches
> - Add patch 16 (AVC_STATS in Kconfig)
> - Prevent free() of static data in xsm_dt_init
>
> FLASK policy updates:
> [PATCH 01/17] flask/policy: split into modules
> [PATCH 02/17] flask/policy: split out rules for system_r
> [PATCH 03/17] flask/policy: move user definitions and constraints
> [PATCH 04/17] flask/policy: remove unused support for binary modules
> [PATCH 05/17] flask/policy: xenstore stubdom policy
> [PATCH 06/17] flask/policy: remove unused example
>
> Hypervisor updates to the FLASK security server:
> [PATCH 07/17] flask: unify {get,set}vcpucontext permissions
> [PATCH 08/17] flask: remove unused secondary context in ocontext
> [PATCH 09/17] flask: remove unused AVC callback functions
> [PATCH 10/17] flask: remove xen_flask_userlist operation
> [PATCH 11/17] flask: improve unknown permission handling
>
> Hypervisor updates to the XSM framework (and its config):
> [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section
> [PATCH 13/17] xen: fix FLASK dependency in Kconfig
> [PATCH 14/17] xsm: annotate setup functions with __init
> [PATCH 15/17] xsm: clean up unregistration
> [PATCH 16/17] xen: Make FLASK_AVC_STATS kconfig option visible
> [PATCH 17/17] xsm: add a default policy to .init.data
I have committed the first two sections. Patch 12 requires an ARM ack,
and patch 13 has some outstanding discussion.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 00/17] XSM/FLASK updates for 4.8
2016-06-21 15:24 ` [PATCH v2 00/17] XSM/FLASK updates for 4.8 Andrew Cooper
@ 2016-06-27 9:48 ` Andrew Cooper
0 siblings, 0 replies; 58+ messages in thread
From: Andrew Cooper @ 2016-06-27 9:48 UTC (permalink / raw)
To: Daniel De Graaf, xen-devel
On 21/06/16 16:24, Andrew Cooper wrote:
> On 20/06/16 15:04, Daniel De Graaf wrote:
>> Changes from v1:
>> - Change c->context and c->sid from arrays to fields when shrinking
>> - Keep struct xen_flask_userlist in headers, but guard it with #ifs
>> - Split off Kconfig changes into their own patches
>> - Add patch 16 (AVC_STATS in Kconfig)
>> - Prevent free() of static data in xsm_dt_init
>>
>> FLASK policy updates:
>> [PATCH 01/17] flask/policy: split into modules
>> [PATCH 02/17] flask/policy: split out rules for system_r
>> [PATCH 03/17] flask/policy: move user definitions and constraints
>> [PATCH 04/17] flask/policy: remove unused support for binary modules
>> [PATCH 05/17] flask/policy: xenstore stubdom policy
>> [PATCH 06/17] flask/policy: remove unused example
>>
>> Hypervisor updates to the FLASK security server:
>> [PATCH 07/17] flask: unify {get,set}vcpucontext permissions
>> [PATCH 08/17] flask: remove unused secondary context in ocontext
>> [PATCH 09/17] flask: remove unused AVC callback functions
>> [PATCH 10/17] flask: remove xen_flask_userlist operation
>> [PATCH 11/17] flask: improve unknown permission handling
>>
>> Hypervisor updates to the XSM framework (and its config):
>> [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section
>> [PATCH 13/17] xen: fix FLASK dependency in Kconfig
>> [PATCH 14/17] xsm: annotate setup functions with __init
>> [PATCH 15/17] xsm: clean up unregistration
>> [PATCH 16/17] xen: Make FLASK_AVC_STATS kconfig option visible
>> [PATCH 17/17] xsm: add a default policy to .init.data
> I have committed the first two sections. Patch 12 requires an ARM ack,
> and patch 13 has some outstanding discussion.
In the interest of getting this work more widely tested, I have pushed
the remaining patches, now that acks have appeared.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 58+ messages in thread