Remove extraneous path_truncate arguments from the AppArmor hook,
as they've been removed from the LSM API.
Signed-off-by: NJames Morris <jmorris@namei.org>

The basic routines and defines for AppArmor policy.  AppArmor policy
is defined by a few basic components.
      profiles - the basic unit of confinement contain all the information
                 to enforce policy on a task

                 Profiles tend to be named after an executable that they
                 will attach to but this is not required.
      namespaces - a container for a set of profiles that will be used
                 during attachment and transitions between profiles.
      sids - which provide a unique id for each profile
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

AppArmor policy is loaded in a platform independent flattened binary
stream.  Verify and unpack the data converting it to the internal
format needed for enforcement.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

ipc:
AppArmor ipc is currently limited to mediation done by file mediation
and basic ptrace tests.  Improved mediation is a wip.

rlimits:
AppArmor provides basic abilities to set and control rlimits at
a per profile level.  Only resources specified in a profile are controled
or set.  AppArmor rules set the hard limit to a value <= to the current
hard limit (ie. they can not currently raise hard limits), and if
necessary will lower the soft limit to the new hard limit value.

AppArmor does not track resource limits to reset them when a profile
is left so that children processes inherit the limits set by the
parent even if they are not confined by the same profile.

Capabilities:  AppArmor provides a per profile mask of capabilities,
that will further restrict.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

AppArmor hooks to interface with the LSM, module parameters and module
initialization.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

AppArmor routines for controling domain transitions, which can occur at
exec or through self directed change_profile/change_hat calls.

Unconfined tasks are checked at exec against the profiles in the confining
profile namespace to determine if a profile should be attached to the task.

Confined tasks execs are controlled by the profile which provides rules
determining which execs are allowed and if so which profiles should be
transitioned to.

Self directed domain transitions allow a task to request transition
to a given profile.  If the transition is allowed then the profile will
be applied, either immeditately or at exec time depending on the request.
Immeditate self directed transitions have several security limitations
but have uses in setting up stub transition profiles and other limited
cases.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

AppArmor does files enforcement via pathname matching.  Matching is done
at file open using a dfa match engine.  Permission is against the final
file object not parent directories, ie. the traversal of directories
as part of the file match is implicitly allowed.  In the case of nonexistant
files (creation) permissions are checked against the target file not the
directory.  eg. In case of creating the file /dir/new, permissions are
checked against the match /dir/new not against /dir/.

The permissions for matches are currently stored in the dfa accept table,
but this will change to allow for dfa reuse and also to allow for sharing
of wider accept states.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

The /proc/<pid>/attr/* interface is used for process introspection and
commands.  While the apparmorfs interface is used for global introspection
and loading and removing policy.

The interface currently only contains the files necessary for loading
policy, and will be extended in the future to include sysfs style
single per file introspection inteface.

The old AppArmor 2.4 interface files have been removed into a compatibility
patch, that distros can use to maintain backwards compatibility.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

A basic dfa matching engine based off the dfa engine in the Dragon
Book.  It uses simple row comb compression with a check field.

This allows AppArmor to do pattern matching in linear time, and also
avoids stack issues that an nfa based engine may have.  The dfa
engine uses a byte based comparison, with all values being valid.
Any potential character encoding are handled user side when the dfa
tables are created.  By convention AppArmor uses \0 to separate two
dependent path matches since \0 is not a valid path character
(this is done in the link permission check).

The dfa tables are generated in user space and are verified at load
time to be internally consistent.

There are several future improvements planned for the dfa engine:
* The dfa engine may be converted to a hybrid nfa-dfa engine, with
  a fixed size limited stack.  This would allow for size time
  tradeoffs, by inserting limited nfa states to help control
  state explosion that can occur with dfas.
* The dfa engine may pickup the ability to do limited dynamic
  variable matching, instead of fixing all variables at policy
  load time.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

AppArmor contexts attach profiles and state to tasks, files, etc. when
a direct profile reference is not sufficient.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

Update lsm_audit for AppArmor specific data, and add the core routines for
AppArmor uses for auditing.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>

Miscellaneous functions and defines needed by AppArmor, including
the base path resolution routines.
Signed-off-by: NJohn Johansen <john.johansen@canonical.com>
Signed-off-by: NJames Morris <jmorris@namei.org>