This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [Xense-devel][RFC][PATCH][0/4] Xen Security Modules: Int

On Fri, 2006-09-01 at 10:58 -0700, Chris Wright wrote:
> * Jun Koi (junkoi2004@xxxxxxxxx) wrote:
> > - So we can use XMS instead of ACM, thus we can remove ACM in the
> > future? (same as LSM, which seems to monopoly the security policy of
> > Linux? )
> The question is whether you can implement ACM policy in the flask
> policy language.  My understanding it yes, it's possible, however it's
> not obvious if it is a win.  I believe the resulting memory footprints
> would not compare well.  Of course, Reiner and George will have a much
> better idea than I ;-)  In general, the advatage of XSM is choice.
> > - LSM has a problem of not supporting stacking module, and that is
> > really paint in the arse. How about XSM? Do you try to fix that
> > problem?
> I don't see anything in XSM that changes that limitation to LSM.  In fact,
> it appears to not even support the very weak stacking via chaining
> mechanism (which is a good plan in this case).  And it's questionable
> at best.  Arbitrary security policies simply do not compose.

We have made a conscious decision not to bring LSM's stacking
capabilities to Xen.  Composition of security policies is difficult at
best, and a given security modules behavior cannot be easily predicted
under arbitrary stacking.  Arbitrary stacking risks eroding the security
goals of an individual module while meeting few or none of the security
goals of the user.  Stacking should be implemented within a security
module that has been designed to stack specific modules to achieve a
specific goal.

> thanks,
> -chris

Xen-devel mailing list