xsm/flask: add distinct SIDs for self/target access

Because the FLASK XSM module no longer checks IS_PRIV for remote
domain accesses covered by XSM permissions, domains now have the
ability to perform memory management and other functions on all
domains that have the same type. While it is possible to prevent this
by only creating one domain per type, this solution significantly
limits the flexibility of the type system.

This patch introduces a domain type transition to represent a domain
that is operating on itself. In the example policy, this is
demonstrated by creating a type with _self appended when declaring a
domain type which will be used for reflexive operations. AVCs for a
domain of type domU_t will look like the following:

scontext=system_u:system_r:domU_t
tcontext=system_u:system_r:domU_t_self

This change also allows policy to distinguish between event channels a
domain creates to itself and event channels created between domains of
the same type.

The IS_PRIV_FOR check used for device model domains is also no longer
checked by FLASK; a similar transition is performed when the target is
set and used when the device model accesses its target domain.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Committed-by: Keir Fraser <keir@xen.org>

1 files changed, 39 insertions, 4 deletions

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 0778a28ecc..ff81b01734 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -68,9 +68,43 @@ HVM domains with stubdomain device models use two types (one per domain):
  - dm_dom_t is the device model for a domain with type domHVM_t
 
 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.
+type is needed for each group of domains. The user field can be used to address
+this for the most common case of groups that can communicate internally but not
+externally; see "Users and roles" below.
+
+Type transitions
+----------------
+
+Xen defines a number of operations such as memory mapping that are necessary for
+a domain to perform on itself, but are also undesirable to allow a domain to
+perform on every other domain of the same label. While it is possible to address
+this by only creating one domain per type, this solution significantly limits
+the flexibility of the type system. Another method to address this issue is to
+duplicate the permission names for every operation that can be performed on the
+current domain or on other domains; however, this significantly increases the
+necessary number of permissions and complicates the XSM hooks. Instead, this is
+addressed by allowing a distinct type to be used for a domain's access to
+itself. The same applies for a device model domain's access to its designated
+target, allowing the IS_PRIV_FOR checks used in Xen's DAC model to be
+implemented in FLASK.
+
+Upon domain creation (or relabel), a type transition is computed using the
+domain's label as the source and target. The result of this computation is used
+as the target when the domain accesses itself. In the example policy, this
+computed type is the result of appending _self to a domain's type: domU_t_self
+for domU_t. If no type transition rule exists, the domain will continue to use
+its own label for both the source and target. An AVC message will look like:
+
+    scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
+
+A similar type transition is done when a device model domain is associated with
+its target using the set_target operation. The transition is computed with the
+target domain as the source and the device model domain as the target: this
+ordering was chosen in order to preserve the original label for the target when
+no type transition rule exists. In the example policy, these computed types are
+the result of appending _target to the domain.
+
+Type transitions are also used to compute the labels of event channels.
 
 Users and roles
 ---------------
@@ -84,7 +118,8 @@ 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.
+grants or event channels, while still allowing communication with the system_u
+user where dom0 resides.
 
 Resource Policy
 ---------------