Re: XSM and the idle domain

[Jan Beulich <jbeulich@xxxxxxxx>]

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:
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?
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?
Please forgive if this sounds like rubbish to you - I may not have a
good enough understanding of the abstract constraints involved here.

Jan