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

[Bryan D Payne <bdpayne@xxxxxxxxxx>]

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

-bryan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel