[lkml]   [2009]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[Patch 0/12] AppArmor security module
    This is the newest version of the AppArmor security module it has been
    rewritten to use the security_path hooks instead of the previous vfs
    approach. The current implementation is aimed at being as semantically
    close to previous versions of AppArmor as possible while using the
    existing LSM infrastructure.

    AppArmor is a wip and is roughly equivalent to previous versions with better
    control of exec transitions. Development is on going and improvements to
    file, capability, network, resource usage and ipc mediation are planned.

    In brief AppArmor is a security module that uses a white list to determine
    permissions. It currently provides rules for file, capability, resource
    and basic network mediation. With its file mediation using path name based
    pattern matching.

    Though it is possible to confine an entire system, AppArmor by design allows
    for application based mediation where only a subset of a running system is
    confined. Any process that is not confined by AppArmor is only restricted
    by the standard unix DAC permission model.

    _Issues Addressed Since Last Time AppArmor was Posted (LSM only)_
    * all issues raised have been address except for return an error out
    of the accept hook which is not a bug but could removed under the
    current simple network mediation model. It was decided instead that
    any development time on addressing this should go towards the new
    network controls instead.
    * The code has seen further cleanups, and has been run through lindent
    and checkpatch again (its been awhile).
    * several bugs have been addressed
    - change_hat auditing
    - quieting of file auditing
    - policy load failures
    - mediation of creation failure under some filesystems

    A brief summary of AppArmor is below

    AppArmor documentation can currently be found at

    The unflattened AppArmor git tree can be found at

    The AppArmor project is currently in transition and will be moving
    away from Novell forge. The current upstream for the AppArmor tools
    can be found at

    The final location of the documentation and mailing lists have
    not been determined and will be updated when known.


    AppArmor's base unit of confinement is a profile, which defines the
    access permissions for tasks it is attached to. Profiles are grouped in
    to profile namespaces, and must have a unique name within the namespace.

    Profile names provide context for when a profile should be used and
    may determine the attachment of a profile to an application. If a profile
    name begins with a / character its name is considered to be a path name
    and it may be matched against executable names to determine attachment.
    Profile names that do not begin with a / character are not considered
    during automatic profile attachment.

    Profile names that begin with / characters can contain AppArmor pattern
    matching and may match against multiple executables. If multiple
    profiles match an executable then the profile with the longest left
    exact match wins. If the winner can not be determined execution of the
    task will fail.

    Profile names that begin with / characters are consider for attachment
    when an unconfined application calls exec, or when a confined application
    uses a exec rules specifying that such a match should be done (px, cx).
    They may also be attached using the change_profile, or change_hat directives.

    Profile's names that don't begin with a / character are only attached
    when they are specified by a profile exec transition, or through using
    that change_profile, change_hat directives.

    A partial sample profile

    /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,


    AppArmor allows for rules that black list permissions by prepending the deny
    keyword, these rules are used to annotate known items that will be encountered
    and should be rejected.

    deny /etc/shadow w,

    please refer to the documentation link for further information

     \ /
      Last update: 2009-11-04 00:51    [W:0.028 / U:2.268 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site