[apparmor] File delegation

[John Johansen]

File delegation (of authority) is the ability to pass an opened file to
a delegate task, giving it access to the delegated file even if the
policy being applied to the delegate would not ordinarily allow it.

Delegation can allow for tighter profiles, while at the same time making
them more flexible (think of sec comp), the trade off being that the
profile no longer contains a static listing of all possible permissions.
This does make analysis of policy more difficult but it is still possible
using tools that can do flow analysis.

AppArmor has always had a base use of implicit delegation, either from
an unconfined parent to its children or in the case of implicit delegation
of deleted files.  Expanding and formalizing file delegation has been
on the agenda for a while and now that apparmor's base has been stabilized
I think its time to consider the details of how we want to do this.

Delegation in AppArmor is profile centric, with the profile confining
the task enumerating what can be delegated.  The unconfined profile
in its default form allows delegating all files opened by a task
(encapsulating the current behavior).  This proposal will only cover
passing of opened files, not of passing rules that could extend a
profile.

Beyond those basics there are several details to be determined.

1. Whether the delegatee profile should have rules controlling receiving of
   delegated files.

   There are several potential choices.
   a). No rule needed, all delegated files are implicitly accepted.

   b). A generic rule indicating the profile allows receiving delegated
       files.  This breaks current behavior for delegation from unconfined
       tasks.  We could make unconfined an exception but I don't believe
       that should be done.

   c). Flexible rules that allow specifying what profiles delegated files
       can be received from.  A generic rule could be written using
       pattern matching.

   d). An implicit generic rule allowing delegated files, with deny rules
       (black listing) that can be used to block delegation.

   e). An implicit generic rule allowing delegation if no delegation rules
       are specified, but if any delegation rule is specified then the
       implicit rule is not used.

2. Whether delegation rules should cover implicit, explicit delegation,
   or both.  For the purpose of this discussion, explicit delegation occurs
   when a task deliberately marks a file for delegation, where implicit
   delegation occurs when a file is passed without the task taking any
   explicit action to mark the file.

   The distinction between implicit and explicit delegation occurs because
   of in unix open files are inherited by default, and a task must explictly
   mark a file as close on exec if it shouldn't be passed.

   Explicit delegation requires the task to mark any files being delegated.
   This requires an API that tasks must take advantage of.  Explicit
   delegation is more secure but it needs modified applications to take
   advantage of it.

   The API used for explicit delegation needs some thought, and can be
   a generic marking of a file, or specific marking of the file as to which
   profiles it can be delegated to.

   The use of fd passing via unix domain sockets is a form of explicitly
   delegating a file, and could potentially be used as part of an API.

   Implicit delegation provides a way to lock down which files are delegated
   via inheritance without modifying applications.

   It is possible to support both models.  The question is whether its worth
   adding the extra complexity.

3. How delegated files are inherited
   When a file is delegated to a child does the authority to access that 
   file also pass down to grand children?

   Also can a child explicitly delegate a file it has inherited access 
   permission to?  That is the right to explicitly redelegate an open file 
   may be different than permission to implicitly inherit said file.

4. How delegation should be expressed in policy
   So I don't have any great ideas on this, and suggestions are more than 
   welcome, basically it will depend on how much we want to be able to 
   specify and some of the choices made above.

   It is also possible that we can choose to use several representations
   so that policy can be tuned as needed

   1. represent it with generic ipc rules.
      ipc w /some/profile,

      The basics behind this is that file delegation can be considered
      a form of ipc, and the information from  a file that the parent
      opens could be shared with a delegatee via other methods of ipc.
      Of course this doesn't cover the full scope, of what permissions
      a delegated file may have but it covers the basic idea.

      Of course it doesn't limit which files from the parent can be
      delegated.  It could be tightened up some by requiring a special
      delegate flag for ipc permissions.

   2. Have a permission flag to that can be added to rules.
      /some/file  rwD,    # allow delegating with any children

      The problem with this one is that it allows the file to be
      delegated to any profile.  As the file isn't paired with potential
      targets.

   3. Allow specifying which matching rules on execs
      /foo/file r,

      /bin/exec px + { /foo/file, ... }

      The problem here is it is tied to the exec so it is hard to specify
      which files can be delegated explicitly by passing an fd over unix
      domain sockets.

   4. Allow specifying specific files, or rule with an ipc rule.
      ipc D /some/profile { /foo/file, ... }