[Apparmor-dev] AppArmor Security Goal 0.2

[Crispin Cowan]

Enhanced based on some feedback from Andreas. In the absence of any
other feedback, I am likely to post this to LKML on Monday.

This post is dual-format ASCII and HTML for my editing convenience. The
final post to LKML will be pure ASCII.

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

AppArmor is intended to protect systems from attackers exploiting
vulnerabilities in applications that the system hosts. The threat is
that an attacker can cause a vulnerable application to do something
unexpected and undesirable. AppArmor addresses this threat by confining
the application to access only the resources it needs to access to
execute properly, effectively imposing "least privilege" execution on
the application. In some cases least privilege will prevent an exploit
from functioning at all e.g. by denying execute access to /bin/bash, and
in other cases least privilege will restrict the damage an attacker can
cause if they can cause the application to execute arbitrary code e.g.
by denying write permission to web site documents.

An application is one or more related processes performing a function,
e.g. the gang of processes that constitute an Apache web server, or a
Postfix mail server. AppArmor *only* confines processes that the
AppArmor policy says it should confine, and other processes are
permitted to do anything that DAC permits. This is sometimes known as a
targeted security policy.

You defend an entire system by using AppArmor to confine each of the
applications on that system that are exposed to potential attack. For
instance, to defend a system against network attack, place AppArmor
profiles around every application that accesses the network. To defend a
system against attack from the console, place AppArmor profiles around
every application that accessed the keyboard and mouse.

AppArmor currently mediates access to files, ability to use POSIX.1e
Capabilities, and coarse-grained control on network access. This is
sufficient to prevent a confined process from *directly* corrupting the
file system. It is not sufficient to prevent a confined process from
*indirectly* corrupting the system by influencing some other process to
do the dirty deed. But to do so requires a complicit process that can be
manipulated through another channel such as IPC. Future versions of
AppArmor will mediate more resources, including finer grained network
access controls, and controls on various forms of IPC.

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 path
      names matching its profile, and only with the permitted modes:
      read, append, write, memory map, execute, and link
    * 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. If an unconfined process is considered an
      unacceptable threat, then confine additional applications until
      adequate security is achieved.
    * 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.
    * A confined process may access a file that has a name that is not
      in its profile via a hard link, IFF the hard link is in the
      confined process's profile. Note that whoever created the hard
      link must have had access to the target file, so to mediate this
      threat, confine additional applications until adequate security is
      achieved.
    * A confined process can operate on a file descriptor passed to it
      by an unconfined process, even if it manipulates a file not in the
      confined process's profile. To block this attack, confine the
      process that passed the file descriptor.
    * 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.
    * Manipulating AppArmor policy requires being both root privileged
      and not confined by AppArmor, thus there is explicitly no
      capability for non-privileged users to change AppArmor policy.
    * AppArmor confines processes if they are children of a confined
      process, or if the name of the exec'd child matches the name of an
      AppArmor profile. Another process could copy a program to a
      different path name and then execute it without confinement, but
      the other process would have to have permission to do so in the
      first place. To prevent this, confined the other process and
      additional applications until adequate security is achieved.
    * Mount and namespace manipulations can be used to arbitrarily
      change the pathnames that files appear at, and thus completely
      bypass AppArmor policy. To prevent this, processes confined by
      AppArmor are currently not permitted to call mount or manipulate
      name spaces at all. A future development may provide more granular
      controls on mount and namespace manipulations.
    * AppArmor does not slice bread, cure cancer, or bring world peace.
      This list may be expanded :)

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://forge.novell.com/pipermail/apparmor-dev/attachments/20071028/350135f8/attachment.html