XSM/Flask v4v controls

This page documents the XSM/Flask v4v controls.  These are presently in addition to the V4V firewall (viptables) rules, which are independent.

In current OpenXT releases, XSM/Flask applies a v4v send permission check between the Flask security contexts of the sending and receiving Xen domains. This permission must be allowed in order for two domains to communicate via v4v; hence, the XSM/Flask policy provides a hard upper bound on allowable v4v communications.  This hard upper bound can be further constrained via the V4V firewall (viptables) rules, which operate at (domain, port) granularity.

In OpenXT master, there is (or soon will be) a further XSM/Flask v4v use permission check between the Flask security context of a domain and itself upon any attempted use of any of the v4v hypercalls.  This permission check may be used to prevent certain domains, such as regular guests, from having any access to the v4v hypercall interface.  This eliminates v4v as an additional hypervisor attack surface for such domains.

The XSM/Flask policy is defined in the xsm-policy git project.  To allow regular guests to use v4v and send to dom0, you will need to uncomment two lines in the policy/modules/xen/guesthvm.te file.  Alternatively, you could define a separate Flask Type Enforcement domain for a particular Xen domain, allow it to use v4v, and assign that domain via the VM configuration, thereby permitting a specific domain to do so without allowing other guests.

Other XSM/Flask v4v controls are planned for the future, to include providing (domain, port) granularity, thereby obsoleting the V4V firewall.