[Xen-changelog] [xen-unstable] flask/policy: Add user and constraint examples

[Xen patchbot-unstable <patchbot@xxxxxxx>]

# HG changeset patch
# User Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
# Date 1328196073 0
# Node ID 87d642dc65bb723fac66a0bfdeb7204174ec293f
# Parent  d2c02f12aa82532ccf6321868d57f85b568d6b48
flask/policy: Add user and constraint examples

These examples show how to use constraints and the user field of the
security label to prevent communication between virtual machines of
different customers in a multi-tenant environment.

Signed-off-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Committed-by: Keir Fraser <keir@xxxxxxx>
---


diff -r d2c02f12aa82 -r 87d642dc65bb docs/misc/xsm-flask.txt
--- a/docs/misc/xsm-flask.txt   Thu Feb 02 15:20:40 2012 +0000
+++ b/docs/misc/xsm-flask.txt   Thu Feb 02 15:21:13 2012 +0000
@@ -27,14 +27,17 @@
 
 FLASK uses only one domain configuration parameter (seclabel) defining the
 full security label of the newly created domain. If using the example policy,
-"seclabel='system_u:system_r:domU_t'" would be used for normal domains. For
-simple policies including the example policy, the user and role portions of the
-label are unused and will always be "system_u:system_r".  Most of FLASK policy
-consists of defining the interactions allowed between different types (domU_t
-would be the type in this example); FLASK policy does not distinguish between
-domains with the same type. This is the same format as used for SELinux
-labeling; see http://selinuxproject.org for more details on the use of the 
user,
-role, and optional MLS/MCS labels.
+"seclabel='system_u:system_r:domU_t'" is an example of a normal domain. The
+labels are in the same format as SELinux labels; see http://selinuxproject.org
+for more details on the use of the user, role, and optional MLS/MCS labels.
+
+FLASK policy overview
+---------------------
+
+Most of FLASK policy consists of defining the interactions allowed between
+different types (domU_t would be the type in this example). For simple 
policies,
+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
@@ -57,8 +60,27 @@
  - domU_t is a domain that can communicate with any other domU_t
  - isolated_domU_t can only communicate with dom0
 
-More types can be added to allow groups of domains to communicate without
-allowing communication between groups, or only between certain groups.
+One disadvantage of using type enforcement to enforce isolation is that a new
+type is needed for each group of domains. In addition, it is not possible to
+allow isolated_domU_t cannot to create loopback event channels without allowing
+two domains of type isolated_domU_t to communicate with one another.
+
+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.
+
+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 dom0.
+
+Resource Policy
+---------------
 
 The example policy also includes a resource type (nic_dev_t) for device
 passthrough, configured to allow use by domU_t. To label the PCI device 3:2.0
diff -r d2c02f12aa82 -r 87d642dc65bb tools/flask/policy/policy/constraints
--- a/tools/flask/policy/policy/constraints     Thu Feb 02 15:20:40 2012 +0000
+++ b/tools/flask/policy/policy/constraints     Thu Feb 02 15:21:13 2012 +0000
@@ -22,6 +22,19 @@
 # role_op : == | != | eq | dom | domby | incomp
 #
 # names : name | { name_list }
-# name_list : name | name_list name            
+# name_list : name | name_list name
 #
 
+# Prevent event channels and grants between different customers
+
+constrain event bind (
+       u1 == system_u or
+       u2 == system_u or
+       u1 == u2
+);
+
+constrain grant { map_read map_write copy } (
+       u1 == system_u or
+       u2 == system_u or
+       u1 == u2
+);
diff -r d2c02f12aa82 -r 87d642dc65bb 
tools/flask/policy/policy/modules/xen/xen.te
--- a/tools/flask/policy/policy/modules/xen/xen.te      Thu Feb 02 15:20:40 
2012 +0000
+++ b/tools/flask/policy/policy/modules/xen/xen.te      Thu Feb 02 15:21:13 
2012 +0000
@@ -22,22 +22,22 @@
 
################################################################################
 
 # The hypervisor itself
-type xen_t, xen_type, domain_type, mls_priv;
+type xen_t, xen_type, mls_priv;
 
 # Domain 0
 type dom0_t, domain_type, mls_priv;
 
 # Untracked I/O memory (pseudo-domain)
-type domio_t, domain_type;
+type domio_t, xen_type;
 
 # Xen heap (pseudo-domain)
-type domxen_t, domain_type;
+type domxen_t, xen_type;
 
 # Unlabeled objects
-type unlabeled_t, domain_type;
+type unlabeled_t, xen_type;
 
 # The XSM/FLASK security server
-type security_t, domain_type;
+type security_t, xen_type;
 
 # Unlabeled device resources
 # Note: don't allow access to these types directly; see below for how to label
@@ -143,7 +143,11 @@
 
 
################################################################################
 #
-# Constraints
+# 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.
 #
 
################################################################################
 
@@ -159,9 +163,19 @@
 
 
################################################################################
 #
-# Labels for initial SIDs and system role
+# 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 -r d2c02f12aa82 -r 87d642dc65bb tools/flask/policy/policy/users
--- a/tools/flask/policy/policy/users   Thu Feb 02 15:20:40 2012 +0000
+++ b/tools/flask/policy/policy/users   Thu Feb 02 15:21:13 2012 +0000
@@ -3,15 +3,9 @@
 # System User configuration.
 #
 
-#
-# gen_user(username, role_set, mls_defaultlevel, mls_range)
-#
-
-#
-# system_u is the user identity for system processes and objects.
-# There should be no corresponding Unix user identity for system,
-# and a user process should never be assigned the system user
-# identity.
-#
+# 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)

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog