> >
> > 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
|
Home
xen.org, 