[Apparmor-dev] AppArmor Object Capability Conference Notes

[Crispin Cowan]

The AppArmor Object Capability IRC "conference" happened this afternoon,
with participation by me, John Johansen, and Rob Meijer. This is my
summary of the discussion:

    * AA's goal is to better secure legacy software, which is largely
      oblivious to the Object Capability programming style
    * OCap advocates (such as Rob Meijer) have a different goal of
      providing infrastructure that facilitates improved programming in
      the OCap style
          o For the common AA case, he designs noted here try to apply
            appropriate OCap style to legacy code where it treats open
            file descriptors as delegable object capabilities, and keep
            it simple for OCap programming that is largely non-existent
            in legacy code
          o For the enhanced OCap infrastructure case, these designs try
            to put the OCap work in user-level libraries, so as not to
            burden AA with complexity that will only be used by new code
    * AA (AppArmor) delegation should be coarse-grained, e.g. "can
      delegate", without regard to what is delegated or to "whom"
          o Not discussed, but from prior e-mail discussion, this should
            apply only to delegation via exec (because it is sloppy) and
            not to delegation via passing FDs via UNIX domain sockets
            (because they are necessarily overt)
          o This feature may become more fine-grained as needs indicate
    * AA kernel module should grow a feature to facilitate delegation of
      POSIX.1e capabilities
          o Rob Meijer wants to be able to delegate some kinds of
            privileges based on delegating directory FDs and other kinds
            of delegation. POSIX.1e Capabilities are the only
            *permissive* hooks in LSM, so this is the only practical way
            to do it without requiring new (weird) LSM hooks.
    * Someone (Rob?) should implement liboccap to provide Object
      Capability functionality that is not absolutely required to be in
      the kernel
          o LKML philosophy is to resist inclusion of anything that is
            not absolutely required to be in-kernel
          o AppArmor philosophy is to be as simple as possible,
            resisting all feature requests that do not provide high
            value:cost ratios for existing (legacy) software
          o A lot of OCap stuff can be done in a user library, with only
            minimal functionality in the kernel
    * libocap should implement safe_execve()
          o provide fine-grained designation of which FDs are to be
            delegated, and which not
          o log to AA the FDs that are being delegated (so that AA can
            create policy that permits this)

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin
CEO, Mercenary Linux		   http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work