diff mbox series

[v13] xsm/flask: correcting initial sid assignment on context allocation

Message ID 20220909012546.21807-1-dpsmith@apertussolutions.com (mailing list archive)
State New, archived
Headers show
Series [v13] xsm/flask: correcting initial sid assignment on context allocation | expand

Commit Message

Daniel P. Smith Sept. 9, 2022, 1:25 a.m. UTC
The current flow for initial SID assignment is that the function
flask_domain_alloc_security() allocates the security context and assigns an
initial SID based on the limited state information it can access. Specifically
the initial SID is determined by the domid of the domain, where it would assign
the label for one of the domains the hypervisor constructed with the exception
of initial domain (dom0). In the case of the initial domain and all other
domains it would use the unlabeled_t SID.

When it came to the SID for the initial domain, its assignment was managed by
flask_domain_create() where it would be switched from unlabeled_t to dom0_t.
This logic worked under the assumption that the first call to
flask_domain_create() would be the hypervisor constructing the initial domain.
After which it would be the toolstack constructing the domain, for which it is
expected to provide an appropriate SID or else unlabeled_t would be used.

The issue is that the assumptions upon which the current flow is built were
weak and are invalid for PV shim and dom0less. Under the current flow even
though the initial domain for PV shim is not set as privileged, flask would
label the domain as dom0_t. For dom0less, the situation is two-fold. First is
that every domain after the first domain creation will fail as they will be
labeled as unlabeled_t. The second is that if the dom0less configuration does
not include a "dom0", the first domain created would be labeled as dom0_t.

This commit only seeks to address the situation for PV shim, by including a
check for xenboot_t context in flask_domain_alloc_security() to determine if
the domain is being constructed at system boot. Then a check for is_privilged
and pv_shim is added to differentiate between a "dom0" initial domain and a PV
shim initial domain.

The logic for flask_domain_create() was altered to allow the incoming SID to
override the initial label. This allows a domain builder, whether it is a
toolstack, dom0less, or hyperlaunch, to provide the correct label for the
domain at construction.

The base policy was adjusted to allow the idle domain under the xenboot_t
context the ability to construct domains of both types, dom0_t and domu_t.
This will enable a hypervisor resident domain builder to construct domains
beyond the initial domain,

Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
---

Split out from series "Adds starting the idle domain privileged", earlier patches
from series have been committed.

Changes in v13:

After considering the points raised by Jason, a valid point that really stuck
is that changes to FLASK should not be made to address that dom0less did not
include support to work under FLASK. The reality is that both dom0less and
hyperlaunch are solutions that by design provide domain definitions to the
hypervisor for construction. Therefore, they should handle doing domain
construction under FLASK. Thus, the patch was adjusted to address correctly
labeling the initial domain under PV shim.

Changes in v12:
- actually send the changes from v11

Changes in v11:
- put back dom0_created variable in flask_domain_create() to ensure the
  enforcement that dom0_t is a singleton label

Changes in v10:
- rewrote commit message
- fixed typos
- reworked logic in flask_domain_create() to be simpler and not result in
  changing the domain security struct before the access check fails


 tools/flask/policy/modules/dom0.te |  3 ++
 tools/flask/policy/modules/domU.te |  3 ++
 xen/xsm/flask/hooks.c              | 55 +++++++++++++++++++++++-------
 3 files changed, 49 insertions(+), 12 deletions(-)

Comments

Jan Beulich Sept. 9, 2022, 6:09 a.m. UTC | #1
On 09.09.2022 03:25, Daniel P. Smith wrote:
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -38,6 +38,12 @@
>  #include <conditional.h>
>  #include "private.h"
>  
> +#ifdef CONFIG_X86
> +#include <asm/pv/shim.h>
> +#else
> +#define pv_shim false
> +#endif

Hmm, yet another instance of such. We have already several (and
dissimilar) instances scattered around, so I guess we really want to
centralize this (e.g. by moving things from x86'es pv/shim.h to a
non-asm header). Not something you need to do right here, but
something for 4.18.

Jan
Jason Andryuk Sept. 9, 2022, 4:11 p.m. UTC | #2
On Thu, Sep 8, 2022 at 9:26 PM Daniel P. Smith
<dpsmith@apertussolutions.com> wrote:
>
> The current flow for initial SID assignment is that the function
> flask_domain_alloc_security() allocates the security context and assigns an
> initial SID based on the limited state information it can access. Specifically
> the initial SID is determined by the domid of the domain, where it would assign
> the label for one of the domains the hypervisor constructed with the exception
> of initial domain (dom0). In the case of the initial domain and all other
> domains it would use the unlabeled_t SID.
>
> When it came to the SID for the initial domain, its assignment was managed by
> flask_domain_create() where it would be switched from unlabeled_t to dom0_t.
> This logic worked under the assumption that the first call to
> flask_domain_create() would be the hypervisor constructing the initial domain.
> After which it would be the toolstack constructing the domain, for which it is
> expected to provide an appropriate SID or else unlabeled_t would be used.
>
> The issue is that the assumptions upon which the current flow is built were
> weak and are invalid for PV shim and dom0less. Under the current flow even
> though the initial domain for PV shim is not set as privileged, flask would
> label the domain as dom0_t. For dom0less, the situation is two-fold. First is
> that every domain after the first domain creation will fail as they will be
> labeled as unlabeled_t. The second is that if the dom0less configuration does
> not include a "dom0", the first domain created would be labeled as dom0_t.
>
> This commit only seeks to address the situation for PV shim, by including a
> check for xenboot_t context in flask_domain_alloc_security() to determine if
> the domain is being constructed at system boot. Then a check for is_privilged
> and pv_shim is added to differentiate between a "dom0" initial domain and a PV
> shim initial domain.
>
> The logic for flask_domain_create() was altered to allow the incoming SID to
> override the initial label. This allows a domain builder, whether it is a
> toolstack, dom0less, or hyperlaunch, to provide the correct label for the
> domain at construction.
>
> The base policy was adjusted to allow the idle domain under the xenboot_t
> context the ability to construct domains of both types, dom0_t and domu_t.
> This will enable a hypervisor resident domain builder to construct domains
> beyond the initial domain,
>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>

Reviewed-by: Jason Andryuk <jandryuk@gmail.com>

Thanks,
Jason
diff mbox series

Patch

diff --git a/tools/flask/policy/modules/dom0.te b/tools/flask/policy/modules/dom0.te
index 0a63ce15b6..f710ff9941 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -75,3 +75,6 @@  admin_device(dom0_t, ioport_t)
 admin_device(dom0_t, iomem_t)
 
 domain_comms(dom0_t, dom0_t)
+
+# Allow the hypervisor to build domains of type dom0_t
+xen_build_domain(dom0_t)
diff --git a/tools/flask/policy/modules/domU.te b/tools/flask/policy/modules/domU.te
index b77df29d56..3f269018f9 100644
--- a/tools/flask/policy/modules/domU.te
+++ b/tools/flask/policy/modules/domU.te
@@ -13,6 +13,9 @@  domain_comms(domU_t, domU_t)
 migrate_domain_out(dom0_t, domU_t)
 domain_self_comms(domU_t)
 
+# Allow the hypervisor to build domains of type domU_t
+xen_build_domain(domU_t)
+
 # Device model for domU_t.  You can define distinct types for device models for
 # domains of other types, or add more make_device_model lines for this type.
 declare_domain(dm_dom_t)
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 8bd56644ef..e7db7fe07a 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -38,6 +38,12 @@ 
 #include <conditional.h>
 #include "private.h"
 
+#ifdef CONFIG_X86
+#include <asm/pv/shim.h>
+#else
+#define pv_shim false
+#endif
+
 static uint32_t domain_sid(const struct domain *dom)
 {
     struct domain_security_struct *dsec = dom->ssid;
@@ -170,6 +176,9 @@  static int cf_check flask_domain_alloc_security(struct domain *d)
     if ( !dsec )
         return -ENOMEM;
 
+    /* Set as unlabeled then change as appropriate. */
+    dsec->sid = SECINITSID_UNLABELED;
+
     switch ( d->domain_id )
     {
     case DOMID_IDLE:
@@ -182,7 +191,13 @@  static int cf_check flask_domain_alloc_security(struct domain *d)
         dsec->sid = SECINITSID_DOMIO;
         break;
     default:
-        dsec->sid = SECINITSID_UNLABELED;
+        if ( domain_sid(current->domain) == SECINITSID_XENBOOT )
+        {
+            if ( d->is_privileged )
+                dsec->sid = SECINITSID_DOM0;
+            else if ( pv_shim )
+                dsec->sid = SECINITSID_DOMU;
+        }
     }
 
     dsec->self_sid = dsec->sid;
@@ -550,20 +565,36 @@  static int cf_check flask_domain_create(struct domain *d, uint32_t ssidref)
     struct domain_security_struct *dsec = d->ssid;
     static int dom0_created = 0;
 
-    if ( is_idle_domain(current->domain) && !dom0_created )
+    /*
+     * If the null label is passed, then use the label from security context
+     * allocation. NB: if the label from the allocated security context is also
+     * null, the security server will use unlabeled_t for the domain.
+     */
+    if ( ssidref == 0 )
+        ssidref = dsec->sid;
+
+    /*
+     * First check if the current domain is allowed to create the target domain
+     * type before making changes to the current state.
+     */
+    rc = avc_current_has_perm(ssidref, SECCLASS_DOMAIN, DOMAIN__CREATE, NULL);
+    if ( rc )
+        return rc;
+
+    /*
+     * The dom0_t label is expressed as a singleton label in the base policy.
+     * This cannot be enforced by the security server, therefore it will be
+     * enforced here.
+     */
+    if ( ssidref == SECINITSID_DOM0 )
     {
-        dsec->sid = SECINITSID_DOM0;
-        dom0_created = 1;
+        if ( !dom0_created )
+            dom0_created = 1;
+        else
+            return -EINVAL;
     }
-    else
-    {
-        rc = avc_current_has_perm(ssidref, SECCLASS_DOMAIN,
-                          DOMAIN__CREATE, NULL);
-        if ( rc )
-            return rc;
 
-        dsec->sid = ssidref;
-    }
+    dsec->sid = ssidref;
     dsec->self_sid = dsec->sid;
 
     rc = security_transition_sid(dsec->sid, dsec->sid, SECCLASS_DOMAIN,