[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

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

> 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.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.