Re: [Xen-devel] [Xen-users] XSM/Flask iomem

[nicolas.poirot@xxxxxxxxx]

Ok thanks.
I didn't suspect checkpolicy to be in charge of this. I used the version 2.5 so 
far.

-----Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> a écrit : -----
A : nicolas.poirot@xxxxxxxxx
De : Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Date : 28/09/2018 21:13
Cc : George Dunlap <dunlapg@xxxxxxxxx>, xen-devel 
<xen-devel@xxxxxxxxxxxxxxxxxxxx>
Objet : Re: [Xen-users] XSM/Flask iomem

This is apparently a mismatch between what the checkpolicy compilation does
and what it is expected to do.  While some parts of checkpolicy do this
sorting, the main compilation flow does not, and the policy compilation
process does not ensure inputs are sorted.  In the future, newer versions
of checkpolicy should fix this bug.  Newer versions of Xen may also start
checking this ordering on policy load (I'll submit a patch to do this).

This bug also applies to I/O ports, but not the other types of policy
items (IRQs, PCI devices, or devicetree).  It will cause non-sorted entries
to be skipped in most cases, instead querying the default sid, but larger
iomem/ioport ranges might also query the skipped entry (always in addition
to the default).

Until the fixed version of checkpoicy is released and adopted, policy
writers can manually sort their iomem/ioport ranges as a workaround.

On 09/27/2018 06:18 AM, George Dunlap wrote:
> [Moving to xen-devel]
> 
> Daniel,
> 
> Any comments on this one?
> 
>   -George
> On Wed, Sep 26, 2018 at 12:41 PM <nicolas.poirot@xxxxxxxxx> wrote:
>>
>> Hi,
>>
>> I just noticed from a bad behaviour of my installation and the 
>> security_iterate_iomem_sids
>> function that the iomem ranges have to be sorted in the device_contexts file.
>> The flask load policy takes iomem ranges declaration as it comes but the sid 
>> attribution
>> and check function expects the list of iomem ocontexts to be sorted.
>> My file didn't comply with this statement which ended to use the default 
>> iomem sid instead
>> of computing one before checking the permission.
>>
>> This doesn't seem to be documented anywhere in the xen release 4.11.0.
>>
>> Thanks.
>>
>> Nicolas
>> 1
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@xxxxxxxxxxxxxxxxxxxx
>> https://lists.xenproject.org/mailman/listinfo/xen-users

1


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel