On Tue, Dec 06, 2016 at 12:53:00PM -0500, Stephen Smalley wrote:
> On 12/06/2016 12:00 PM, Gary Tierney wrote:
> > Hi,
> >
> > I've been working on optimizing out AV rules with no applicable
> > types as well as unused attributes to trim down the size of a
> > policy which uses CIL blocks and attributes extensively. Looking
> > into the avtab code (and how creating a new avtab is implemented in
> > expand.c) I have a question:
> >
> > Does the following suffice for taking an existing avtab and
> > creating a new one with all of its elements? Or do I need to
> > consider avtab_insert_nonunique() like expand.c does? If I'm
> > following the expand_avtab() code correctly, I'd think I'd need to
> > consider conditional avtabs in the following code:
> >
> > static int copy_avtab_map_fn(avtab_key_t *key, avtab_datum_t
> > *datum, void *args) { avtab_t *avtab = (avtab_t *) args;
> >
> > return avtab_insert(avtab, key, datum); }
> >
> > static int copy_avtab(avtab_t *avtab, avtab_t **out) { avtab_t *tmp
> > = NULL; if (avtab_init(tmp)) { return POLICYDB_ERROR; }
> >
> > if (avtab_alloc(tmp, MAX_AVTAB_SIZE)) { return POLICYDB_ERROR; }
> >
> > if (avtab_map(avtab, copy_avtab_map_fn, tmp)) { return
> > POLICYDB_ERROR; }
> >
> > *out = tmp; return POLICYDB_SUCCESS; }
> >
> > Is that the right idea?
> >
> > Thanks.
>
> Did you consider doing this at the CIL layer instead, given that CIL
> already does similar optimizations and has more semantic information
> available? Note that CIL used to be more aggressive about removing
> unused attributes but backed off because some attributes are used in
> neverallows and we want to preserve those for neverallow checking in CTS.
>
Yes, I think I'll go down that route eventually once I move on to removing
typeattributes with no good AV rules. This was mostly an exercise in getting
my feet wet with the binary policy and figuring out what makes up the
majority of its size. I noticed that the CIL compiler currently does
optimize away typeattributes that aren't used in any AV rules so the
foundation seems to be there (and Jim also shared some input on this
previously: http://marc.info/?l=selinux&m=147871772206496&w=2).
> Conditional rules can indeed have non-unique entries, and so can
> xperms rules.
>
>
Thanks, that makes sense.
--
Gary Tierney
GPG fingerprint: 412C 0EF9 C305 68E6 B660 BDAF 706E D765 85AA 79D8
https://sks-keyservers.net/pks/lookup?op=get&search=0x706ED76585AA79D8
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
