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

[Crispin Cowan]

Dominic Reynolds wrote:
> 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.
>   
I really like the choice of k for locking.

> 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.
>   
Ok. But note that w permissions is a strict superset of a permissions,
so the merge rule would be that conflicting w/a rules can be replaced
with w rules.

> 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.
>   
Its great to finally have this in for real. Hopefully this time it will
stick :)

> 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
>   
Good clean up. Do we have a script to transform files old->new?

> 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
>   
Good cleanup. Same script question.

>  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.
>   
This is a really interesting generalization of change_hat. It should be
especially useful for profiling KDE.

> 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
>   
This lets you have popups on your desktop to alert you when something
has been PERMITted or REJECTed, and to connect other custom DBUS
listeners to AppArmor.


> 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.
>   
I think this is the most exciting feature in this release, and should
tremendously improve the ability for the community to collectively
improve the profiles.

Crispin