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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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

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

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


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