|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [Xense-devel][RFC][PATCH][1/4] Xen Security Modules: XSM
xense-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 09/01/2006
03:37:07 PM:
> > > set_bit(_DOMF_privileged, &dom0->domain_flags);
> > > /* post-create hooks sets security label
*/
> > > acm_post_domain0_create(dom0->domain_id);
> > > +
> > > + xsm_complete_init(dom0);
> >
> > Seems this should drop the acm hook here, no?
> >
>
> We did not want the XSM patch to add XSM and remove ACM because we
do
> not believe that the community sees ACM and sHype as the distinct
> entities that they really are. That's why we have the patch
that
> removes the duplicated hooks and code and produces a module called
ACM.
> Hopefully in the future XSM will refer to the security framework and
the
> the STE/Chinese Wall functionality of ACM will be called the sHype
> module.
>
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!
Regards
Reiner_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel
|
|
|
|
|