On Aug 27, 2013 8:12 AM, "Stephen Smalley" <[email protected]> wrote:
>
> On 08/26/2013 08:29 PM, William Roberts wrote:
> > On Aug 26, 2013 4:41 PM, "Stephen Smalley" <[email protected]> wrote:
> >> I think I'd rather have an explicit extraCategories= output selector.
> >> But you'd need to expand the number of categories to provide a range
> >> that is not ever used by the levelFrom= code to ensure no conflicts.
> >
> > Yeah... I'm still not keen on adding an extra output selector.
> >
> >> And some caution is advised there; due to some inefficiency in the
> >> representation, significant increases in the number of categories can
> >> have a non-trivial affect on policy size.
> >>
> >>
> > Yes I've seen this before.
> >
> > I think I'm just going to add a wildcard support to level... Something
like
> > all %a get replaced with appid, etc.
>
> I think that will get a NAK from me. I think using categories and an
> explicit extraCategories= specifier is the right way to go. Increasing
> MLS_CATS from 1024 to 1280 (allowing 256 categories for use by the
> extraCategories=, which is probably excessive) only increases policy
> size by 4K, so it isn't onerous. And if we got to the point where we
> truly needed to massively increase the number of categories, we know how
> to solve the policy size problem; it just requires a change to the
> policy format (and thus a version bump). But I don't think we're there
yet.
>
>
>
I think adding extra fields is not the proper solution and also sets a
dangerous precedence. I'm probably going to attempt to merge this change
then into Google's tree (not sure of the reception due to mls nature).
However, competing implementations are always welcome. If no one accepts
it, its not an issue to maintain in my tree.
