| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
Reiner Sailer wrote:
<snip>
XSM would effectively replace the small set of hooks that the
sHype/ACM module introduced with a more generic mediation framework.
sHype would use the XSM hook framework to control the same operations
that it controls now. The way users interact with sHype(XSM) (tools,
policies, labeling, ...) would not be affected by XSM. Instead of
being both hooks and security module, sHype(XSM) would be a security
module and XSM would offer the hooks.
Ideally, XSM would be a standardized and generic Xen interface that
offers the possibility for researchers to easily experiment with
proprietary security modules. At the same time, it must have very low
performance overhead and be effective to support enterprise security
on highly utilized platforms.
It is very good for starting the discussions that George and team
succeeded to submit their code before the Xen Summit. Thank you!
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.
Sincerely,
John
--
J.P. McDermott building 12
Code 5542 mcdermott@xxxxxxxxxxxxxxxx
Naval Research Laboratory voice: +1 202.404.8301
Washington, DC 20375, USA fax: +1 202.404.7942
_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
|
|
|
| |
|
Home