[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |