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

[Stefan Berger <stefanb@xxxxxxxxxx>]

Ewan,

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel