[Apparmor-dev] AppArmor Security Goal

[Crispin Cowan]

Arjan van de Ven asked that AppArmor for LKML upstreaming (and in fact
all future LSMs) should have a description attached to it, so that the
code can be compared against the goal. So here goes, a relatively short
description of what AppArmor hopes to achieve.

Comments welcome. In particular:

    * Is this the right level of detail?
    * Things I should say that I left out?
    * Things that I did say that should be left out?

Thanks,
    Crispin
------------------------------------------------------------------------

AppArmor Application Security For Linux
Crispin Cowan, PhD
MercenaryLinux.com

AppArmor is designed to address the application security problem, which
is to ensure that attackers cannot cause applications to do something
undesirable. AppArmor does this by applying access controls to a
specified application, so that when ever that application runs, it is
restricted to only access the operating system resources that it has
been granted. AppArmor *only* confines processes that the AppArmor
policy says it should confine, and other processes are permitted to do
anything that DAC (Discretionary Access Controls, the traditional Linux
security controls) permits. This is sometimes known as a targeted
security policy.

Total isolation, so that a process cannot affect other processes, is
impossible because there are always side effects from sharing the
resources managed by an operating system. Therefore all access control
systems achieve only an approximation to isolation by mediating some
aspects of process behavior. AppArmor currently mediates access to
files, ability to use POSIX.1e Capabilities, and coarse-grained control
on network access.Future versions of AppArmor will mediate more
resources, including finer grained network access controls, and controls
on various forms of IPC.

AppArmor seeks to be easy to configure and maintain by system
administrators. To achieve that, AppArmor specifies the programs to be
confined and the resources they can access in a syntax similar to how
those resources are natively accessed. So file access controls are
specified using absolute paths with respect to the name space the
process is in, including embedded shell syntax wild cards. POSIX.1e
capabilities are specified by name. Network access controls currently
are specified by simply naming the protocol that can be used e.g. tcp,
udp, and in the future will be more general, resembling firewall rules.

Thus the AppArmor security goal should be considered piecewise from the
point of view of a single confined process: that process should only be
able to access the resources specified in its profile:

    * can only access files that are reachable in its name space by
      names matching its profile
          o read pathnames marked readable
          o append to pathnames marked appendable
          o write pathnames marked writable
          o memory-map files marked mappable
          o link permission on the name a hard link will point to
          o execute pathnames marked executable
          o execute pathnames marked executable
                + the policy to be applied to the child is determined by
                  the parent's policy
    * can only use the POSIX.1e capabilities listed in the profile
    * can only perform the network operations listed in the profile

Security issues that AppArmor explicitly does *not* address:

    * Processes that are not confined by AppArmor are not restricted in
      any way by AppArmor
    * A process that is not permitted to directly access a resource can
      influence some other process that does have access to the resource
      may do so, if the "influence" is a permitted action
    * Process activities not currently mediated by AppArmor are
      permitted, e.g. confined processes can perform any IPC that DAC
      permits, other than signals as mediated by CAP_KILL

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


-- 
Crispin Cowan, Ph.D.               http://mercenarylinux.com/
	       Itanium. Vista. GPLv3. Complexity at work