Re: [Xen-devel] XSM denials with 4.7.0 RC1

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 5/4/16 2:39 PM, Konrad Rzeszutek Wilk wrote:
>>
>> Well it turns out yes I was using a bad policy. I grabbed the policy
>> updates from master and not from 4.7.0-rc1 when I merged them with my
>> policy. So yes the above are incorrect and noise on my part. master
>> wasn't (and still isn't) at the same point that 4.7.0-rc1 was at.
>>
>>>
>>>> (XEN) avc:  denied  { xen_commandline } for domid=1
>>>> scontext=system_u:system_r:domU_t tcontext=system_u:system_r:xen_t
>>>> tclass=version
>>>> (XEN) avc:  denied  { xen_build_id } for domid=1
>>>> scontext=system_u:system_r:domU_t tcontext=system_u:system_r:xen_t
>>>> tclass=version
>>>
>>> If these show up for domUs in normal operation (and I think using
>>> "xl devd" probably qualifies for that), then they probably need
>>> dontaudit rules.
>>>
>>
>> These are still happening for any domD running "xl devd".
> 
> Is 'domD' not part of domain_type?
> 
> As in the policy has:
> 
> allow domain_type xen_t:version {                                             
>   
>     xen_extraversion xen_compile_info xen_capabilities                        
>   
>     xen_changeset xen_pagesize xen_guest_handle                               
>   
> };  
> 
> Is domD under a different type? In which case it sounds as if you
> are using a non-default XSM policy?
> 

I'm calling it domD (since I'm passing a device into it) but its a domU.
Ignore my wording. I've got a few extra allows at the bottom of the
default policy to allow a PCI device to be passed in.

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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