|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkb
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.
Reiner_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|