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

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

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

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