Re: [PATCH v4 7/7] tools, libxl: handle the iomem parameter with the memory_mapping hcall

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 04/02/2014 05:45 AM, Ian Campbell wrote:
> On Tue, 2014-04-01 at 16:52 -0400, Daniel De Graaf wrote:
>> Currently, XEN_DOMCTL_memory_mapping is allowed to device model domains
>> whereas XEN_DOMCTL_iomem_permission is restricted to dom0 only.  This is
>> probably the reason why an iomem_access_permitted check is not present
>> in XEN_DOMCTL_iomem_permission.
>>
>> If FLASK is enabled, both domctls do the same permission checking based
>> on the security label of the memory range: that the current domain has
>> the RESOURCE__{ADD,REMOVE}_IOMEM permission, and the target domain has
>> the RESOURCE__USE permission.  This prevents the sock-puppet method from
>> being used to permit arbitrary accesses to created domains, but requires
>> that these restrictions be done at the granularity of the security
>> labels, which may not be as flexible as preferred in some setups.
>
> So the builder domain would have permission per iomem_access_permitted
> to use the range, but would not actually be able to do so due to lack of
> RESOURCE__USE?

Without changes, the domain builder would not need to have permission per
the rangeset. Since the modification to the rangeset is what triggers the
RESOURCE__USE check, if the domain builder did not have USE then it would
not pass iomem_access_permitted.  With the access check added, the USE
permission would be required to for the add/remove permissions to do
anything.  The permission isn't a complete subset because any relabeling
of resources makes this more complicated.

> And it can give that access to someone else by virtue of
> RESOURCE__{ADD,REMOVE}_IOMEM?

Right.

>> While the current design does allow for a domain builder to manage
>> resources that it cannot directly use on its own, I don't think this was
>> ever really a design decision.  There are few (if any) security gains
>> from being able to block a domain builder from accessing resources if it
>> can create domains that access these resources, since it can just create
>> sock-puppet domains or corrupt the domain with access.
>
> Right.
>
>> I think changing XEN_DOMCTL_iomem_permission to require the current
>> domain to pass an iomem_access_permitted check before permitting access
>> is reasonable.  It will require some adjustments to my domain builder
>> series which currently relies on the old behavior, but those should be
>> fairly simple (cloning the rangesets instead of swapping).  If this
>> change is made, I think similar changes to the other rangeset domctls
>> (irq, ioport) should be done at the same time.
>
> Yes, consistency here would be good.
>
> Ian.

-- 
Daniel De Graaf
National Security Agency