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.poi...@bertin.fr> 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-us...@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-users
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
