[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [PATCH] [XEND] Xen-API support for ACM


we understand the importance of supporting multiple access control models in Xen. The XSPolicy API will continue to work even if XSM is accepted into Xen, as XSM is a security module framework designed to support different access control models and our XSPolicy class tries to reflect that. In fact, we built the XSPolicy API with multiple security modules in mind and include selectors that differentiate between today's ACM or other security modules and their policies being managed.

What is the plan  for XSM acceptance into Xen? We have not seen any public discussion on this topic and would certainly welcome a discussion. We believe that XSM can adequately support sHype/ACM, and although we have performance and complexity concerns, we are generally in favor of such a generalized security architecture for Xen.

  Stefan and Reiner

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 02/06/2007 10:26:15 AM:

> On Fri, Jan 26, 2007 at 10:56:42AM -0500, Stefan Berger wrote:
> > This patch is adding initial Xen-API support for the sHype access
> > control module so that functionality that can be reached via 'xm'
> > commands can also be reached using the Xen-API.
> >
> > This patch adds a security_label to the VM class, which is to be set
> > when ACM is enabled. Access control to the block interface is now
> > enforced in blkif.py and denied if the system's policy does not allow a
> > VM to access a block interface.
> >
> > Future patches will extend this part of the Xen-API and lib-xen and
> > provide (latex) documentation.
> >
> > The module is designed to also support other policies than ACM
> when they become available.
> Have you had any feedback on this work from those involved with XSM?  I'd
> rather not drop anything into the 1.0 Xen-API without a wider review, because
> I know that there's a lot of working going on in this area, and I wouldn't
> want to lock XSM out of the API by accident.
> In fact, this seems like something that would be ideal to present at the next
> Xen Summit, so that we can strengthen the API in this area before we declare
> it stable and supported.  Do you have any plans in that regard?
> As a general principle, I've pared down the 1.0 API to the things that we're
> really very sure about, because this is going to be an API that we maintain
> at the wire-level over the long term.  I'm not convinced that this patch meets
> that criterion, and would be a lot more comfortable once it's had some wider
> review within the community.
> Don't worry about missing the "1.0 deadline" as it were -- there areplenty of
> features that haven't made it in, and we're actively working to ensure that
> clients will be able to make use of new features when they become available.
> Cheers,
> Ewan.
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.