XSM: new set of "avc denied"

XSM: new set of "avc denied"

[Wei Liu]

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

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.

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.

Wei.

[0] http://logs.test-lab.xenproject.org/osstest/logs/57005/

Re: XSM: new set of "avc denied"

[Ian Campbell]

On Mon, 2015-05-25 at 10:40 +0100, Wei Liu 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".

Thanks for picking up on these, I was just about to.

> 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
> 
> 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.

Yes, this seems to be the biggest cause of failures

> 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.

I think this is from the use of xen_raw_console_write early on in the
Linux pvops kernel.

By default these would be nop on a debug=n hypervisor, and they are
controllable with the guest_loglvl hypervisor option in both debug
cases, I think.

I think XSM rejecting is valid, but I'd also be happy with a change to
allow it and rely on the handling via the console options as folks like.

Ian.

>  My guess is that HVM is not
> configured to write to console so I don't see that in HVM test cases.


Correct, although I would expect hvmloader to have been even more
chatty, guess I am wrong about that.

FWIW I saw quite a few of these from the stubdom mini-os when I tested
stub-dm as well.

Ian.

Re: XSM: new set of "avc denied"

[Jan Beulich]

>>> 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)...

> 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.

> 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?

Jan

Re: XSM: new set of "avc denied"

[Daniel De Graaf]

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