Kernel side variables

[John Johansen]

This is meant to kick off a discussion for future planning on kernel
side variables.  There are no immediate work items off of this but
I want to start accumulating discussions so that actual long term
planning can take place.

Currently AppArmor's variables are expanded in user space.  This
requires reloading policy just to flip a conditional toggle.  It
also means variables can not be as fine grain as they could be, if
they were resolved when used.  Eg. @{PID} when it was used expanded
to a regex pattern, with kernel side variables this could be an
exact match against the tasks pid allowing much tighter locking
down of /proc/

There are two distinct types of kernel variables that could be
supported.  Those that implicitly exist like, tasks pid, uid,
etc., and those that are loaded from user space.

Loading some variables from userspace has two advantages over
just expanding them when the policy is compiled.  Variables
could be easily toggled without having to recompute and
reload policy, and variables used as part of pattern matching
could be more precise.

Eg you could load a table of home directories and index it by
the kernel uid variable, giving a custom home directory.  Something
like
@{HOME} = @{HOME_TABLE[@{EUID}]}


The problems I see with loaded variables are: they add complexity to
the kernel (but not much more than just support implicit kernel
variables), ensuring that they properly synced and determining
which ones should be loaded instead of just expanded at policy.

So what kernel variables do we want to support and are variables
loaded from userspace worth doing.