[Apparmor-dev] [RFC] AppArmor 2.1 Feature Overview

[Dominic Reynolds]

Per the irc discussion on #apparmor I wanted post for review the planned changes
around the 2.1 release for AppArmor. This release will ship as part of
openSUSE 10.3 and Ubuntu "gutsy". Feedback/corrections welcome :)

This version will be also released as tarballs and maintained in a branch on
forge svn.


Profile Language Features/Changes:
------------------------------

o File Locking Mediation

  Mediation of advisory and mandatory file locking by applications has been
  added with this release. This feature introduces a new permission character
  "k" in the profile language to indicate that the specified resource is allowed
  to perform the relevant locking operation.

o File Append Mediation

  Mediation of appending writes has been added. This feature introduces a new
  permission character "a" to indicated this operation is allowed. The "a"
  permission is mutually exclusive to the "w" permission, i.e. the a given rule
  may include "w" or "a" but not both.


o Network Mediation

  Coarse grained network access control has been added to this release.  This
  feature allows mediation of network access based on address type and family.


  syntax 
    'network' [[<domain>] [<type>] [<protocol>]] ','

  The protocol specification is very limited and in the general case 'network
  <domain> <type>' will be emitted by the module in access denied messages, and
  output by the profile generation tools.

 
  <domain> = "inet", "ax25", "ipx", "appletalk", "netrom", "bridge", "atmpvc",
             "x25", "inet6", "rose", "netbeui", "security", "key", "packet",
             "ash", "econet", "atmsvc", "sna", "irda", "pppox", "wanpipe",
             "bluetooth",

           The domains "llc", "iucv", "tipc" are currently mediated but can not
           be specified.  Too allow them wide open networking must be used. ie
           the rule network, this will be fixed

  <type>   = "stream", "dgram", "seqpacket", "rdm", "raw", "packet"

           The type "dccp" is currently not allowed but this will get fixed

  <protocol> = "tcp", "udp", "icmp"

  eg.                                                                                                                          
  network,              # allow all networking              
  network inet,         # allow use of all inet networking
  network inet stream,  # allow tcp                    

  network inet tcp,     # dito                      
  network tcp,          # allow inet and inet6 tcp,

  Note: The tools currently support family and type specification only. This
        however fully supports the feature as only type and family are emitted
        by the module and allows full generation of profiles to mediate network
        behavior supported by the module.



o Modification to Directory handling


  New syntax to distinguish directories from files.

  The previous behavior made no explicit handling for directories. The new
  kernel module makes access to directories explicit and distinguished by the
  addition of a trailing '/' to a rule that identifies it as a directory.

  Old Behavior:

  /path/to/somewhere     r, # Gives read access to the path 
                            # whether a file or directory

  /path/to/somewhere/*   r, # Read access to all files and directories
                            # in /path/to/somewhere

  /path/to/somewhere/**  r, # Read access to all files and directories
                            # under /path/to/somewhere


  New Behavior:
    
  /path/to/somewhere/*  r, # Gives read access to files in the directory 

  /path/to/somewhere/   r, # Gives read access to the directory 
                           # element only

  /path/**/              r, # Gives read access to all directory entries
                            # under /path


  /path/to/somewhere/**  r,  # Gives access to files and directories under 
                             # /path/to/somewhere


o Modification to change_hat syntax 

  The syntax for the hat syntax in a profile has been modified. The hat is still
  specified within the profile but is specified as

    /PROFILE//HAT_NAME
 
    rather than ^HATNAME

  As a consequence - the '^' character can now be properly used in pathnames and
  character classes 

  /foo[^b]   # used to be broken /foo[ and hat b] even if it was
             # in a file rule instead of specifying a profile now it is handled
             # correctly
 

o Change Profile Feature

  A new change_profile policy specification was added.  Change_profile is
  similar to change_hat but allows changing to any profile (including hats), not
  just hats.  The restriction is that the profiles that can be changed to must
  be specified.  To change to a hat via change_profile instead of change_hat the
  hat name is specified by separating the profile and hat_name with //

   syntax
   'change_profile' <profile> ','

   eg.
   change_profile /bin/foo,   #allow change_profile to /bin/foo
   change_profile /bin/foo//hat  # allow change_profile to ^hat in /bin/foo

Note: this feature is not configurable via the profiling tools.



Userspace Changes
-----------------


o AppArmor LAF dispatcher for DBUS

  A dispatcher for the Linux Audit Framework that sends AppArmor events to
  consumer applications via DBUS message bus. This must be configured via the
  auditd.conf file in order to be registered as a dispatcher for audit events.

  For more info:

  https://forgesvn1.novell.com/svn/apparmor/trunk/management/apparmor-dbus/README



o AppArmor logparsing library

  A library which provides an api to access AppArmor data from system log files.
  The library supports the Linux Audit Framework format and the standard syslog
  format.



o Support for Network Repository for profile storage

  The AppArmor profile tools now interact with local and remote repositories of
  profiles to supply the user with profiles when profiles are needed for
  applications and to allow central storage of AppArmor profiles accross
  multiple machines.

  * Selecting profiles from a repository:
    The user is prompted to select a profile from one or more users in the
    network repository or from the local inactive profile repository
    (/etc/apparmor/profiles/extras). 

  * Storing profiles in a repository
    The user has the option of storing profiles in a remote repository. The user
    is reqiured to supply a username, password, and email address to
    create/access an account on the repository server and then the
    new/changed profiles can be stored on the remote server.



o AppArmor Desktop Applet for Gnome

    A desktop applet for gnome that AppArmor events via dbus.