Re: [Xen-devel] XSM: new set of "avc denied"

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.05.15 at 11:40, <wei.liu2@xxxxxxxxxx> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel