[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 05/26/2015 05:34 AM, Jan Beulich wrote:
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)...

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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.