[apparmor] policy size

John Johansen john.johansen at canonical.com
Tue Nov 8 23:21:50 UTC 2011


So this is just an update on what is being done to address policy size, in
the same vein as the "Slow apparmor policy compilation" mail.

compiled policy size is a big concern and we already use a compressed dfa
format, to reduce dfa size.  With that said we are working on several
improvements, though I can't give a time frame for when they will hit.

So what are we working on/planned for

full minimization
  this is part of the permissions rework, and it will allow use to remove
  all redundant states.

accept indexing
  Again part of the permission rework, this changes how permissions are
  stored in the dfa.  Instead of having a wide accept perm per state
  we will have an index per state, into a shared permission table.  Since
  the vast majority of permissions are shared this can result in
  significant savings.

  It is also needed to make dfa sharing possible as it separates separate
  a profiles permissions from the dfa.

state differential compression
  Currently we are just using a comb compression on the states next/check
  table.  With state differently compression we can reduce the number of
  transitions in the next/check table, we will continue to use comb
  compression on top of this.

equivalence classes
  Currently we don't use equivalence classes which would can help improve
  the packing achieved by the comb compression.

DFA/HFA sharing
  Currently every profile/hat has its own dfa.  We are working towards
  allowing the dfa to be shared.  As policy share a lot of common patterns
  this will result in a reduced total policy size.

kernel vars, counting constraints, and back references
  Natively supporting these can actual reduce the size of the dfa

hfa
  moving to a hybrid nfa/dfa with boundry/gateway states will help to
  control the exponential explosion that can occur in pure dfas.
  Basically this is aiming for something that is near nfa size with
  dfa speed.  If done right it can actually be faster as it has
  better caching properties.


Some of these improvements will hit next cycle, as they are part of
the permission rework (full minimization, accept indexing), while
others are a little further out.

cheers
john



More information about the AppArmor mailing list