AppArmor/Changes AppArmor 2 1

From openSUSE

AppArmor 2.1 Features/Changes

This release is a feature update to AppArmor 2.0.x It is deployed in openSUSE 10.3 and Ubuntu "Gutsy"

Profile Language Features/Changes

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.

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. The "a" permission is actually a subset of the "w" permission. Granting "w" permission implicitly allows O_APPEND writes, but granting "a" permission does not allow non-O_APPEND writes. If you've initially granted "a" permission in a profile and then discover that you need non-O_APPEND writes after all, you just need to upgrade the "a" to a "w" instead of adding both "a" and "w" in the same profile rule.

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.

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

Message format changes

The messages emitted by the AppArmor kernel module have changed in this relase. These changes make AppArmor more consistent with standard usage of the Linux Audit Framework and utilize the message typing available to make log file parsing and the profile management tool development less complex. The updated message format utlizes the following message (operation) types:

 #define AUDIT_APPARMOR_AUDIT    1501    /* AppArmor audited grants */ 
 #define AUDIT_APPARMOR_ALLOWED  1502    /* Allowed Access for learning */
 #define AUDIT_APPARMOR_DENIED   1503 
 #define AUDIT_APPARMOR_HINT     1504    /* Process Tracking information */
 #define AUDIT_APPARMOR_STATUS   1505    /* Changes in config */
 #define AUDIT_APPARMOR_ERROR    1506    /* Internal AppArmor Errors */

Other data is provided in the body of the message in name value pairs.

The AppArmor module will still default to syslog if the Linux Audit Framework infrastructure is not availalble.

Modification to change_hat

The reporting of change_hat related events and information has changed. The log messages and profile state (as available via /proc/<pid>/attr/current) are reported as:

   /profile//hat

This change should be transparent to most users from the last release.

Modification to chroot handling

The handling of chroot has been changed. AppArmor now prepends the root of the chroot to all access in a chroot environment. This means that profiles and rules that are to be accessible in the chroot environment need to have the chroot environment path prefixed.

This allows mixing of both pre-chroot and post-chroot rules in a profile, where both pre-chroot and post-chroot rule paths are accessible before a chroot but only the post-chroot rules are available after a chroot.

The transition to a chroot environment does not change currently enforced or attached profiles but it does affect which profiles can become attached. All process in the chroot will only attach to profiles with the chroot environment path prepended. This enables the chroot environment to have a different set of profiles than the non-chroot environment.

 eg.
 A chroot environment has been set up at /jail/
 A program /bin/confined_example does a chroot to /jail after the chroot only the rules with the /jail/ prefix are available.

   /bin/confined_example {
      /lib/**.so rm,             #rule available before chroot but NOT after
      /jail/lib/**.so rm,        #rule available before chroot and after
                                 #will match /lib/**.so  within the chroot
      /jail/bin/example px,      #path for an executable in the chroot
                                 #will be used to match /bin/example with in the chroot
      ...,
   }

 Within a chrooted eviron profile attachment from unconfined programs still occurs, but it is done against profile with the chrooted environment prepended. So when trying to run a program from unconfined shell that has been chrooted to /jail

 chrooted env shell >/bin/example

 The attachment for the profile will match /jail/bin/example

Minor Syntax Bug Fixes

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

The , character is no longer a valid character in a filename in the case it is the last character before whitespace

 /foo,bar    #valid  
 /foobar,    #invalid

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

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

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.

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 across 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 required 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.

AppArmor Desktop Applet for Gnome

A desktop applet for gnome that receives and displays AppArmor reject events via dbus.

For the applet to be able to display rejects the AppArmor LAF dispatcher for D-Bus must be installed and enabled.