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

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

[George S. Coker, II]

The following patches expand on the original ACM security framework
contributed by IBM.  These patches create a general security module
framework called Xen Security Modules (XSM).  The present implementation
is not complete, but we are releasing the XSM prototype in preparation
for presentation and discussion at next week's Xen summit.

The first patch in this series provides XSM functionality for Xen.  The
XSM is modeled after similar functionality found in Linux under the
Linux Security Modules (LSM).  XSM provides a dedicated security
namespace, general support for a module defined security hypercall,
general support for policy discovery during boot, and a default (dummy)
security module, as well as an extensible security hook interface.

The second patch in this series demonstrates the existing ACM security
engine, sHype, as an XSM module.  Additional nativization and
optimization of the sHype module to the XSM interface remains, but the
prototype is consistent with functionality found in non-XSM Xen.

The third patch in this series introduces a new security module called
Flask.  Flask provides a flexible mandatory access control security
architecture similar to the security architecture in SELinux.  The Flask
XSM module is a work in progress, but is an example of a module that
employs all of the features of XSM.

The fourth patch in this series provides a sample policy for Flask.  The
practical use of the sample policy is limited to exercising XSM hooks
and can only be used in permissive/warning mode.  Subsequent policy
releases will track dom0/domU behavior and be enforceable.

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

[Jun Koi]

Hi George,

Awesome, you guys have done a great job!!!

Few questions:

- 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? )

- 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?

Will look at the code as soon as I have time :-)

Thanks.
Jun

On 9/2/06, George S. Coker, II <gscoker@alpha.ncsc.mil> wrote:
> The following patches expand on the original ACM security framework
> contributed by IBM.  These patches create a general security module
> framework called Xen Security Modules (XSM).  The present implementation
> is not complete, but we are releasing the XSM prototype in preparation
> for presentation and discussion at next week's Xen summit.
>
> The first patch in this series provides XSM functionality for Xen.  The
> XSM is modeled after similar functionality found in Linux under the
> Linux Security Modules (LSM).  XSM provides a dedicated security
> namespace, general support for a module defined security hypercall,
> general support for policy discovery during boot, and a default (dummy)
> security module, as well as an extensible security hook interface.
>
> The second patch in this series demonstrates the existing ACM security
> engine, sHype, as an XSM module.  Additional nativization and
> optimization of the sHype module to the XSM interface remains, but the
> prototype is consistent with functionality found in non-XSM Xen.
>
> The third patch in this series introduces a new security module called
> Flask.  Flask provides a flexible mandatory access control security
> architecture similar to the security architecture in SELinux.  The Flask
> XSM module is a work in progress, but is an example of a module that
> employs all of the features of XSM.
>
> The fourth patch in this series provides a sample policy for Flask.  The
> practical use of the sample policy is limited to exercising XSM hooks
> and can only be used in permissive/warning mode.  Subsequent policy
> releases will track dom0/domU behavior and be enforceable.
>

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

[Jun Koi]

On 9/2/06, Jun Koi <junkoi2004@gmail.com> wrote:
> Hi George,
>
> Awesome, you guys have done a great job!!!
>
> Few questions:
>
> - 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? )

Of course here I meant SELinux monopolies the Linux kernel, not LSM subsystem :)

Thanks.
Jun

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

[Chris Wright]

* Jun Koi (junkoi2004@gmail.com) 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.

thanks,
-chris

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

[Robert Watson]

On Fri, 1 Sep 2006, Chris Wright wrote:

>> - 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.

I'm not entirely convinced that the theoretically hard problem of arbitrary 
policy composition is that much of a problem in practice.  A number of systems 
(RSBAC on Linux, kauth(9) on Mac OS X, the MAC Framework on FreeBSD and Mac OS 
X, and the fixed compositions of MAC policies in many trusted systems) have 
illustrated that you can do a lot of useful things using a fixed composition 
that is effectively a logical and of granted rights.  That isn't the same as 
stacking, of course, since the composition happens in the containing 
framework, rather than in the policies.  Obviously, there are limitations to 
this approach, but for many things, it works quite well in quite a few 
deployed real-world systems with moderately diverse policies.

Robert N M Watson
Computer Laboratory
University of Cambridge

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

[George S. Coker, II]

On Fri, 2006-09-01 at 10:58 -0700, Chris Wright wrote:
> * Jun Koi (junkoi2004@gmail.com) 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

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

[Chris Wright]

* George S. Coker, II (gscoker@alpha.ncsc.mil) wrote:
> On Fri, 2006-09-01 at 10:58 -0700, Chris Wright wrote:
> > * Jun Koi (junkoi2004@gmail.com) wrote:
> > > - 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.

Yes, I think that's a wise decision (that's what I meant by good plan).

> 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.

Indeed.  Sorry if my wording above was misleading, I'm in complete
agreement.

thanks,
-chris


> 
> George
> > thanks,
> > -chris
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

[Chris Wright]

* Robert Watson (robert@fledge.watson.org) wrote:
> On Fri, 1 Sep 2006, Chris Wright wrote:
> >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.
> 
> I'm not entirely convinced that the theoretically hard problem of arbitrary 
> policy composition is that much of a problem in practice.  A number of 
> systems (RSBAC on Linux, kauth(9) on Mac OS X, the MAC Framework on FreeBSD 
> and Mac OS X, and the fixed compositions of MAC policies in many trusted 
> systems) have illustrated that you can do a lot of useful things using a 
> fixed composition that is effectively a logical and of granted rights.  
> That isn't the same as stacking, of course, since the composition happens 
> in the containing framework, rather than in the policies.  Obviously, there 
> are limitations to this approach, but for many things, it works quite well 
> in quite a few deployed real-world systems with moderately diverse policies.

No argument that it's possible to create useful compositions, especially with
framework imposed limitations like you mentioned.  But the flask policy model
is not the kind that I'd like to see composed with random other security models.

thanks,
-chris

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

[James Morris]

On Fri, 1 Sep 2006, Robert Watson wrote:

> framework, rather than in the policies.  Obviously, there are limitations to 
> this approach, but for many things, it works quite well in quite a few 
> deployed real-world systems with moderately diverse policies.

Keep in mind that Flask allows for structured and analyzable composition 
of security models, so this will be possible with XSM.


- James
-- 
James Morris
<jmorris@redhat.com>