Re: XSM and the idle domain

[Daniel Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

---- On Thu, 22 Oct 2020 04:13:53 -0400 Jan Beulich <jbeulich@xxxxxxxx> wrote 
----

 > On 22.10.2020 03:23, Daniel P. Smith wrote: 
 > > On 10/21/20 10:34 AM, Hongyan Xia wrote: 
 > >> Also, should idle domain be restricted? IMO the idle domain is Xen 
 > >> itself which mostly bootstraps the system and performs limited work 
 > >> when switched to, and is not something a user (either dom0 or domU) 
 > >> directly interacts with. I doubt XSM was designed to include the idle 
 > >> domain (although there is an ID allocated for it in the code), so I 
 > >> would say just exclude idle in all security policy checks. 
 > > 
 > > The idle domain is a limited, internal construct within the hypervisor 
 > > and should be constrained as part of the hypervisor, which is why its 
 > > domain id gets labeled with the same label as the hypervisor. For this 
 > > reason I would wholeheartedly disagree with exempting the idle domain id 
 > > from XSM hooks as that would effectively be saying the core hypervisor 
 > > should not be constrained. The purpose of the XSM hooks is to control 
 > > the flow of information in the system in a non-bypassable way. Codifying 
 > > bypasses completely subverts the security model behind XSM for which the 
 > > flask security server is dependent upon. 
 >  
 > While what you say may in general make sense, I have two questions: 

[Apologies for any poor formatting, responding from webmail interface ( ._.)]

Hey Jan, these are very legitimate questions.

 > 1) When the idle domain is purely an internal construct of Xen, why 
 >  does it need limiting in any way? In fact, if restricting it in a 
 >  bad way, aren't you risking to prevent the system from functioning 
 >  correctly? 

Think in terms of least privilege, do you want the idle domain and by extension 
the hypervisor to have the additional privilege of imposing state on to the 
system as opposed to processing the state changes. I am not saying it is wrong 
technical approach (though I do believe at a minimum the implementation 
approach is flawed), I am just asking is it wise from a privilege delegation 
aspect of whether it could be done differently from a technical stand point. 
The underlying concern here is once you grant the privilege the hypervisor will 
forever have the privilege which can be used for good (LU) and bad 
(corruption). Take for instance what is being attempted with DomB, in this 
approach the privilege to impose state (configure domains) is delegated to the 
Boot Domain but it is not delegated the privilege to create state (domain 
creation). As I mentioned before, this is what Jason was suggesting in having 
another domain type that is allowed to impose the state that is transitioned to 
from the idle domain to conduct the action.

Whether or not the idle domain is allowed to make hypercalls is not necessarily 
a concern of the XSM hooks. If it is decided that this is the desired path, 
then what is of concern is that the corrective action does not weaken/break the 
hooks. If this ends up being the desired approach, then IMHO the correct action 
is to update the dummy policy, flask policy, and SILO (if it applies) to allow 
the privilege/access to occur versus putting bypasses into the security hooks.

 > 2) LU is merely restoring the prior state of the system. This prior 
 >  state was reached with security auditing as per the system's 
 >  policy at the time. Why should there be anything denind in the 
 >  process of re-establishing this same state? IOW can't XSM checking 
 >  be globally disabled until the system is ready be run normally 
 >  again?

There is an assumption you made there that is being overlooked and that is you 
are assuming it is the same state. It is important to understand what 
assumptions are being made and when possible impose those assumptions through 
policy than with code. Not everyone will want to make the same assumptions and 
may want a better controlled path for that state to flow.

No you don't want to globally disable the XSM checking as that means you have 
lost all control over the system where any and all policy violations could 
occur without any auditing. This would open a huge hole for a malicious actor 
to take advantage of for an attack against the system. 

In the end to reiterate, if this is decided to be the desired approach then 
IMHO the correct implementation is to encode the access in policy not in 
bypasses to the XSM hooks.

 > Please forgive if this sounds like rubbish to you - I may not have a 
 > good enough understanding of the abstract constraints involved here. 

No worries, it is always better to question when in doubt than making an 
assumption. Hopefully I helped in providing a better explanation.

 > Jan 
 >