[lkml]   [2007]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectAppArmor Security Goal
    re-sent due to a typo in addressing.

    AppArmor Security Goal
    Crispin Cowan, PhD

    This document is intended to specify the security goal that AppArmor is
    intended to achieve, so that users can evaluate whether AppArmor will
    meet their needs, and kernel developers can evaluate whether AppArmor is
    living up to its claims. This document is *not* a general purpose
    explanation of how AppArmor works, nor is it an explanation for why one
    might want to use AppArmor rather than some other system.

    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.

    Applications have access to a number of resources including files,
    interprocess communication, networking, capabilities, and execution of
    other applications. The purpose of least privilege is to bound the
    damage that a malicious user or code can do by removing access to all
    resources that the application does not need for its intended function.
    For instance, a policy for a web server might grant read only access to
    most web documents, preventing an attacker who can corrupt the web
    server from defacing the web pages.

    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.

    AppArmor does not provide a "default" policy that applies to all
    processes. So to defend an entire host, you have to piece-wise confine
    each process that is exposed to potential attack. For instance, to
    defend a system against network attack, place AppArmor profiles around
    every application that accesses the network. This limits the damage a
    network attacker can do to the file system to only those files granted
    by the profiles for the network-available applications. Similarly, to
    defend a system against attack from the console, place AppArmor profiles
    around every application that accessed the keyboard and mouse. The
    system is "defended" in that the worst the attacker can do to corrupt
    the system is limited to the transitive closure of what the confined
    processes are allowed to access.

    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. A "complicit" process
    is either a malicious process the attacker somehow got control of, or is
    a process that is actively listening to IPC of some kind and can be
    corrupted via IPC.

    The only IPC that AppArmor mediates is access to named sockets, FIFOs,
    etc. that appear in the file system name space, a side effect of
    AppArmor's file access mediation. 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 users are accustomed to accessing
    those resources. So file access controls are specified using absolute
    paths with respect to the name space the process is in. 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 only access a file if it has at least one
    of the files aliases specified in its profile. If a file alias is
    not specified in the profile then it can not be accessed by that
    path. The creation of aliases needs to be tightly controlled in
    confined applications, hard links creation should be limited to
    provide adequate security.
    * 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 being 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, confine 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.
    CEO, Mercenary Linux
    Itanium. Vista. GPLv3. Complexity at work

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-11-08 22:37    [W:0.027 / U:31.988 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site