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

Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM



On Tue, 2006-09-05 at 12:25 -0400, John McDermott (U.S. Navy Employee)
wrote:

> The XSM concept looks good for prototyping and research but any 
> security-related additions to Xen should be done in a way that does not 
> increase the _minimum_ size of the code base. A small code base is 
> essential for high assurance; having the  flexibility of XSM is good but 
> it should be possible to build a Xen with something smaller than XSM. If 
> XSM or other security enhancements become too deeply associated with the 
> core of Xen then we loose the chance to build high-assurance Xen-based 
> products.
> 
> This is really an issue about what kind of security the hypervisor 
> should enforce and what should be enforced by trusted or untrusted (wrt 
> the hypervisor) mechanisms outside the hypervisor.

I want to make a few points to clarify the value of XSM for Xen.  I
think the value goes well beyond prototyping and research.

1) XSM itself is small.  Do not confuse XSM with XSM and any particular
security module.  XSM has actually made Xen smaller by encapsulating
existing security code into a module that is not part of Xen.  XSM
without a module does not add security value to Xen.  XSM can only
provide security value in the presence of a security module.  In fact,
if you wish to have no security in Xen, XSM allows that too through the
selection of the dummy module.

2) Any arguments about Xen's size and assurance needs to include Xen
with a security module and what the security module is doing for Xen.
Discussion about particular security functionality can now be done in
the context of a particular module not Xen.  This adds value because we
can now reason about what a particular security module is doing for Xen.

3) Analysis of Xen as a security kernel is only appropriate in the
context of a particular security model.  Whether that model is
implemented in an XSM module or littered about Xen is immaterial.  
One might argue that XSM now creates a well defined internal security
interface for Xen and makes it easier to reason about Xen as a security
kernel.

4) Security in user-space needs a secure foundation.  XSM allows that to
be created on Xen with an appropriate choice of module.  No one is
arguing that all security should be implemented as an XSM module.  XSM
modules should only incorporate security functionality appropriate for
the hypervisor; the remainder should be implemented in user-space.

George

> Sincerely,
> 
> John
> 



_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel


 


Rackspace

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