WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xense-devel

Re: [Xense-devel] ACM doesnt scale

To: aq <aquynh@xxxxxxxxx>
Subject: Re: [Xense-devel] ACM doesnt scale
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Fri, 24 Jun 2005 22:22:41 -0400
Cc: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 25 Jun 2005 02:21:56 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <9cde8bff05062408341b43394b@xxxxxxxxxxxxxx>
List-help: <mailto:xense-devel-request@lists.xensource.com?subject=help>
List-id: "A discussion list for those developing security enhancements for Xen." <xense-devel.lists.xensource.com>
List-post: <mailto:xense-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xense-devel>, <mailto:xense-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xense-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > 
> > Could you plesae be a little more specific about the "scaling"?  What 
is
> > your
> > application of the ACM module that determines there's a "scaling" 
problem?
> > 
> 
> at the moment, all the security models (chinesewall (A) and ste (B))
> are hard-coded, and we have 3 combinations of models (not count NULL
> policy): A, B and A_AND_B.
> 
> i guess that there are more models to come in the future, suppose 3:
> C, D, E. so we will have much more combinations. and obviously the
> current organization of code in ACM doesnt scale to that change.
> 
> regards,
> aq
> 
> 
I can't see how it does not scale. If you would like to add a new policy,
you just write a file alike those that are implementing chinese wall or
type enforcement. Then you set primary or secondary policy to this model.

For example, if you would like to use a multi-level security policy 
instead 
of the type enforcement policy, then just register the your multi-level 
policy.

One thing that seems benefitial here would be separate #defines
for the separate policies instead of a single one. Other than that
you might need to add one or two lines of code to the acm_init that 
sets the policies according to the two separate #defines for primary
and secondary policy. If need be, the acm_init can VERY easily be 
adapted to the need.

Since all policy-specific management functions (init, dumppolicy, 
setpolicy,initstate...) are defined in the hooks, the management 
scales as well (if code-size and complexity is the factor).

Not such a big deal.

Reiner

_______________________________________________
Xense-devel mailing list
Xense-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xense-devel

<Prev in Thread] Current Thread [Next in Thread>