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

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



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.

George
> thanks,
> -chris



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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