lkml.org 
[lkml]   [2007]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subject[AppArmor 00/41] AppArmor security module overview
    This post contains patches to include the AppArmor application security
    framework, with request for inclusion.

    The patch series consists of four areas:

    (1) Pass struct vfsmount through to LSM hooks.

    Tony Jones has posted almost all of these patches here before on
    February 5; the feedback given has been incorporated.

    (2) Fixes and improvements to d_path:

    (a) make it unambiguous and exclude unreachable paths from
    /proc/mounts,

    (b) make its result consistent in the face of remounts,

    (c) introduce d_namespace_path(), a variant of d_path that goes up
    to the namespace root instead of the chroot.

    Part (a) has been in the -mm tree for more than a month; this
    series includes a copy of the -mm patch. Parts (b) and (c)
    shouldn't be too controversial.

    (3) Be able to distinguish file descriptor access from access by name
    in LSM hooks.

    Applications expect different behavior from file descriptor
    accesses and accesses by name in some cases. We need to pass this
    information down the LSM hooks to allow AppArmor to tell which is
    which.

    (4) The AppArmor LSM itself.

    (See below.)

    A tarball of the kernel patches, base user-space utilities, example
    profiles, and technical documentation (including a walk-through) are
    available at:

    http://forgeftp.novell.com//apparmor/LKML_Submission-April_07/


    The rest of this introduction gives a brief overview of AppArmor's
    overall design. We will try to address the concerns people had when
    AppArmor was previously posted here in April 06 in a follow-up post.


    AppArmor's Overall Design
    =========================

    AppArmor protects systems from vulnerable software by confining
    processes, giving them "least privilege" access to the system's
    resources: with least privilege, processes are allowed exactly what they
    need, nothing more, and nothing less. Systems are thus protected from
    bugs in applications that would lead to privilege escalation, such as
    remote system access because of a buffer overflow in a web server, etc.

    AppArmor does this by defining application profiles which list allowed
    accesses, and assigning those profiles to processes. AppArmor does *not*
    require the user to confine all processes on the system. Rather, you
    need to provide AppArmor profiles for every process that is potentially
    subject to manipulation by the attacker. For instance, to defend against
    network attack, confine all process that access the network.

    The corollary to this is that attacks against AppArmor that start with
    "assume some unconfined process does ..." are outside the AppArmor
    threat model. Any process that might do something malicious to an
    AppArmor system should be confined by an AppArmor profile.

    The kernel manages many different kinds of resources. AppArmor
    currently controls access to two key resources among them: files, and
    POSIX Capabilities. (Additional protection for things like rlimits,
    interprocess communication, and network access are being worked on, and
    are expected to become available in a future version.)


    File Access Control
    -------------------

    Application profiles control file access by pathname: each profile
    contains a list of fully qualified pathnames (potentially containing
    globbing) and associated access modes: read (r), write (w), different
    kinds of execute (ix, Px, px, Ux, ux), create hard-link (l), and memory
    map for execution (m).

    For example, the following two rules permit read access to any file
    below /srv/www/htdocs/**.html, and memory map for execution (m), execute
    inheriting the current profile (ix), and read (r) access to
    /usr/sbin/suexec2:

    /srv/www/htdocs/**.html r,
    /usr/sbin/suexec2 mixr,


    POSIX Capabilities
    ------------------

    Application profiles enumerate the POSIX capabilites that a process may
    use. (A process must have a capability both in its effective
    capabilities set and in its profile in order to use it. See the
    capabilities(7) manual page for details on capabilities.)

    For example, the following rule allows processes to chroot(2):

    capability sys_chroot,


    An Example Profile
    ------------------

    Here is an example profile for ntpd:

    /usr/sbin/ntpd {
    #include <abstractions/base>
    #include <abstractions/nameservice>

    capability ipc_lock,
    capability net_bind_service,
    capability setgid,
    capability setuid,
    capability sys_chroot,
    capability sys_resource,
    capability sys_time,

    /drift/ntp.drift rwl,
    /drift/ntp.drift.TEMP rwl,
    /etc/ntp.conf r,
    /etc/ntp/drift* rwl,
    /etc/ntp/keys r,
    /etc/ntp/step-tickers r,
    /tmp/ntp* rwl,
    /usr/sbin/ntpd rmix,
    /var/lib/ntp/etc/ntp.conf.iburst r,
    /var/lib/ntp/drift rwl,
    /var/lib/ntp/drift.TEMP rwl,
    /var/lib/ntp/drift/ntp.drift r,
    /var/lib/ntp/var/run/ntp/ntpd.pid w,
    /var/log/ntp w,
    /var/log/ntp.log w,
    /var/run/ntpd.pid w,
    }

    Briefly, the /usr/sbin/ntpd in line 1 tells AppArmor to use this profile
    for /usr/sbin/ntpd. The include lines pull in some predefined
    abstractions containing frequently used access patterns which allow to
    keep profiles short, and the capability and file access rules have been
    explained above.

    Explaining the AppArmor design in detail would take by far too much
    space here, so let me refer you to the technical documentation for that.
    Included is a low-level walk-through of the system and basic tools, and
    some examples. The manual pages included in the apparmor-parser package
    are worth a read as well.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-04-12 11:59    [W:3.979 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site