From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH v4 7/7] tools, libxl: handle the iomem parameter with the memory_mapping hcall Date: Wed, 02 Apr 2014 10:14:47 -0400 Message-ID: <533C1B57.9040201@tycho.nsa.gov> References: <1395712976-19454-1-git-send-email-avanzini.arianna@gmail.com> <1395712976-19454-8-git-send-email-avanzini.arianna@gmail.com> <1396365211.8667.236.camel@kazak.uk.xensource.com> <533B26FC.8040205@tycho.nsa.gov> <1396431945.8667.281.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1396431945.8667.281.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "paolo.valente@unimore.it" , Keir Fraser , Stefano Stabellini , "xen.org" , Dario Faggioli , Julien Grall , Tim Deegan , "xen-devel@lists.xen.org" , Julien Grall , Eric Trudeau , Jan Beulich , Arianna Avanzini , "viktor.kleinik@globallogic.com" List-Id: xen-devel@lists.xenproject.org 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