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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkback driver
From: Bryan D Payne <bdpayne@xxxxxxxxxx>
Date: Mon, 24 Jul 2006 16:09:52 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Reiner Sailer <sailer@xxxxxxxxxx>
Delivery-date: Mon, 24 Jul 2006 13:11:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <3f4fd71695b1d398013e722e6ba41572@xxxxxxxxxxxx>
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
> 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.

For these reasons, we feel that it is most appropriate to perform the check
in xm tools *and* at the point of access.  If you envision users using
blktap to replace blkback, then I believe that we should add similar hooks
to blktap.


Xen-devel mailing list