Questions regarding partial policy load, and the future

[John Johansen]

So just to be upfront this is long term planning, there is no immediate
work items out of this.

Currently AppArmor profiles are completely independent from each other
when compiled and they can and are loaded separately.

However there are several reasons to change this and have policy, or
parts of policy, sharing information and loaded together.  The caveat
is that with sharing the ability to load profiles separately is lost.
So the question becomes how important is being able to load profiles
individually?  How often are individual profile reloads used instead of
just reloading all of policy through the init scripts?

If AppArmor switched to a total policy load model the ability to load
individual profiles could be simulated by allowing the specification
of the profile to load and then grabbing the rest of policy and
recompiling and loading.  To cut down on recompile time policy could
be cached and precompiled pieces could be linked together.

There is no doubt that using total policy load would result in
slower load/compile times than just loading an individual profile.
However this is partially balanced by the fact that loading policy
(all profiles) would be faster than the current one at a time behavior.


So what are the reasons to switch to a total policy load.

* Networking will require it, well at least for part of the network
  policy.  Currently network mediation is very rudimentary.  This is
  partly because to support packet based mediation at least part of
  the networking rule set is going to have to be computed across all
  profiles and loaded as a single global set.

* Total policy load will reduce the size of policy as currently
  there is a lot of redundancy and being able to share dfas
  will result in smaller compiled policy sizes.  As an example
  the current Ubuntu evince profile, is actually 3 profiles that
  share a lot in common, and if their dfas were combined total
  policy size would shrink by about half.

  This will also be beneficial for kernel side variables, of which
  at least some will have to be loaded from a global view instead
  of a per profile view

* Total policy load will allow computing shared "labeling" values
  that will allow speeding up some parts of the kernel mediation
  (less revalidation, etc).  And also is beneficial to a hybrid
  model, where on disk label can be selectively used.


None of these reason require moving to a total policy load for
everything.  The load could be split and only the parts of networking
and kernel side variables that require it could be loaded in the
total policy manner.

However if the computations need to be done for those then its a
small step to do it for everything and in so doing pickup all
the benefits of a total policy load.