Re: XSM: new set of "avc denied"

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 05/26/2015 05:34 AM, Jan Beulich wrote:
>>>> On 25.05.15 at 11:40, <wei.liu2@citrix.com> wrote:
>> I had a look at Osstest's latest xen-unstable run [0]. With Ian's patch
>> series we finally passed the point of guest creation on x86.
>>
>> We now have a new set of "avc denied".
>>
>> May 24 20:18:05.945118 (XEN) avc:  denied  { get_vnumainfo } for domid=1
>> scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
>> tclass=domain2
>>
>> This is HVM loader trying to call get_vnumainfo
>
> Isn't this because get_vnumainfo is in the same (domctl) set as
> set_vnumainfo in the policy (in
> tools/flask/policy/policy/modules/xen/xen.*)? But considering that
> init_vnuma_info() returns "void", I'd expect this to be benign
> anyway (other than preventing NUMA related ACPI tables being
> set up in the guest)...

Even if failure is benign, there is no reason to prevent a guest from
querying its own NUMA information, and apparently reason to permit it.

>> May 24 20:28:50.593013 (XEN) avc:  denied  { logdirty } for domid=0 target=3
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t
>> tclass=shadow
>> May 24 20:29:20.721085 (XEN) avc:  denied  { disable } for domid=0 target=3
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t
>> tclass=shadow
>> May 24 20:29:20.737023 (XEN) avc:  denied  { disable } for domid=0 target=3
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t
>> tclass=shadow
>>
>> The above failures made guest local migration test fail for both PV and HVM
>> guests.
>
> The only shadow related entry I can see in the policy is
>
> 	allow $1 $2:shadow enable;
>
> in create_domain_common. Assuming that anything not listed
> explicitly gets denied, it would be no surprise for the above to
> fail.

Yes, XSM policies are default deny.  Both of these are just missing an allow
rule in the policy.

>> May 24 14:36:47.541016 (XEN) avc:  denied  { writeconsole } for domid=1
>> scontext=system_u:system_r:domU_t tcontext=system_u:system_r:xen_t tclass=xen
>>
>> This is PV specific, I think it was due to PV guest was configured to write
>> to
>> console and XSM (rightfully?) rejected that. My guess is that HVM is not
>> configured to write to console so I don't see that in HVM test cases.
>
> I guess there may be a need to have debug and non-debug policies:
> While in release builds guests aren't allowed to write to the console,
> in debug builds we permit this without XSM, and hence perhaps so
> should the default/example policy?

Instead of creating two separate policies, the XSM policy supports runtime
configuration for enabling rules like this.  This mechanism appears to be
broken at the moment, which I have now fixed.  Once the series is applied,
running "flask-set-bool guest_writeconsole off" will disable this
permission, which defaults to on.  Actual output to the console is also
controlled by log levels, so this may not even be needed to hide the output
in normal use.

-- 
Daniel De Graaf
National Security Agency