On Mon, Mar 2, 2020 at 9:22 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > On Mon, Mar 2, 2020 at 1:45 PM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > On Mon, Mar 2, 2020 at 10:46 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > > > Hm... this is probably a consequence of the second patch. Types are no > > > longer considered a superset of an attribute containing a single type, > > > so the single-type rule gets removed instead of the attribute one... > > > But even before it picked the first rule only by chance (it was first > > > in order). I would say that picking a single-type rule over an > > > attribute rule in this case is outside of the scope of the algorithm. > > > Shouldn't the compiler automatically expand each attribute that has > > > less than 5 types in it? I recall seeing something in the code that > > > did this. I think this was in the CIL part of libsepol, so maybe it > > > applies only when compiling from CIL? > > > > secilc has -G and -X options for controlling expansion of attributes, but > > there aren't equivalent settings in semanage.conf to control when > > building modular policies. > > Internally it all uses the libsepol CIL support so it ought to be fixable. > > Looks like the default is 1 in cil_db_init() so it only happens when > > the attribute has no types by default? Okay, I don't know where I got the "5" boundary from... maybe my brain just made it up. > > Apparently that was to eliminate attributes that have no types at all. > Seems like we could add new options to semanage.conf to provide equivalents > to secilc -G and -X, and have semanage_direct_commit() call > cil_set_attrs_expand_generated() > and cil_set_attrs_expand_size() in the same manner as secilc does based on those > semanage.conf settings. > > Could also look at increasing the default size to 5 or something and > see what impact that has on > Fedora policies. Well, for a start we could increase the default to 2, which should only remove those attributes that have only one type. That has practically no downsides (other than making it a bit harder to trace the rule back to source policy) and would be just enough to make the optimization work nicely. I wouldn't change the default to higher values than that for now, since such values already trade off policy size increase for rule lookup performance, which is more of a gray area. -- Ondrej Mosnacek <omosnace at redhat dot com> Software Engineer, Security Technologies Red Hat, Inc.
