This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkb

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkback driver
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Mon, 24 Jul 2006 20:21:14 -0400
Cc: Bryan D Payne <bdpayne@xxxxxxxxxx>
Delivery-date: Mon, 24 Jul 2006 17:21:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OF95F83550.BF987DA4-ON852571B5.006BF6EE-852571B5.006EC053@LocalDomain>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

Bryan D Payne/Watson/IBM wrote on 07/24/2006 04:09:52 PM:

> > Wouldn't this be better checked in the tool stack, rather than the
> > particular block device driver (which is as likely to be blktap as
> > blkback in future -- control tools would provide a point of common
> > infrastructure to make this check, regardless of choice of actual
> > backend driver)?

> We decided to perform the check at this level based on the
> philosophy that enforcement is most secure when it occurs closest to
> the point of access.  The code path from the xm tools to the point
> of access for a vbd is substantial.  Most notably, data travels
> through the XenStore, where the backend driver obtains the
> information used to connect the vbd to a domain.  If the only
> enforcement was in xm tools, then any other process could add data
> to the XenStore, effectively bypassing the security enforcement.

> You probably noticed that our previous patch to xm tools also
> performs this security check.  The motivation for performing the
> check at the xm tools level is to provide meaningful feedback to
> users.  If we didn't perform the check at the xm tools level, the
> user would only notice that the vbd failed to connect and would have
> to look into /var/log/messages to discover the reason.  This is
> because it is hard to pass an error condition (e.g., access denied)
> from the backend driver to the xm tools.

Bryan's differentiation makes sense to me. The hooks serve different purposes:

The xm tools hook is the "usability hook" that ensures users that domains that get started actually can access their resources.

The block-backend hook is the "enforcement hook" that independently enforces access control at the time when a resource is mounted.

Right now, both hooks are in the 'large' Domain0. I can imagine that the xm create resource validation hook eventually moves into a Xen management GUI that verifies at management time if a domain configuration is "policy-conform". The block-backend hook could eventually move together with the block-backend device into a block device domain for run-time policy enforcement.

Xen-devel mailing list