diff options
| -rw-r--r-- | docs/misc/xsm-flask.txt | 42 | ||||
| -rw-r--r-- | tools/flask/policy/policy/constraints | 15 | ||||
| -rw-r--r-- | tools/flask/policy/policy/modules/xen/xen.te | 28 | ||||
| -rw-r--r-- | tools/flask/policy/policy/users | 14 |
4 files changed, 71 insertions, 28 deletions
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt index 2eb75d6f4a..285bb9ff53 100644 --- a/docs/misc/xsm-flask.txt +++ b/docs/misc/xsm-flask.txt @@ -27,14 +27,17 @@ FLASK_ENABLE to "y"; this change requires a make clean and rebuild. 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 @@ that can be used without dom0 disaggregation. It has two main types for domUs: - 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 --git a/tools/flask/policy/policy/constraints b/tools/flask/policy/policy/constraints index beb949c9b6..765ed4d0cd 100644 --- a/tools/flask/policy/policy/constraints +++ b/tools/flask/policy/policy/constraints @@ -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 --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te index ac52c3fd99..67dd0dfa88 100644 --- a/tools/flask/policy/policy/modules/xen/xen.te +++ b/tools/flask/policy/policy/modules/xen/xen.te @@ -22,22 +22,22 @@ attribute mls_priv; ################################################################################ # 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 @@ delegate_devices(dom0_t, domU_t) ################################################################################ # -# 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 @@ neverallow * ~event_type:event { create send status }; ################################################################################ # -# 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 --git a/tools/flask/policy/policy/users b/tools/flask/policy/policy/users index a0205e5462..35ed8a9334 100644 --- a/tools/flask/policy/policy/users +++ b/tools/flask/policy/policy/users @@ -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) |