2.1 Breaking a Novell AppArmor Profile into Its Parts

The easiest way of explaining what a profile consists of and how to create one is to show the details of a sample profile, in this case for a hypothetical application called /usr/bin/foo: 

#include <tunables/global>

# a comment naming the application to confine
/usr/bin/foo
{
   #include <abstractions/base>

   capability setgid,
   network inet tcp,

   link /etc/sysconfig/foo -> /etc/foo.conf,
   /bin/mount            ux,
   /dev/{,u}random     r,
   /etc/ld.so.cache      r,
   /etc/foo/*            r,
   /lib/ld-*.so*         mr,
   /lib/lib*.so*         mr,
   /proc/[0-9]**         r,
   /usr/lib/**           mr,
   /tmp/                r,
   /tmp/foo.pid          wr,
   /tmp/foo.*            lrw,
   /@{HOME}/.foo_file   rw,
   /@{HOME}/.foo_lock    kw,
   owner /shared/foo/** rw,
   /usr/bin/foobar       cx,
   /bin/**               px -> bin_generic,


   # a comment about foo's local (children)profile for /usr/bin/foobar.

   profile /usr/bin/foobar {
      /bin/bash          rmix,
      /bin/cat           rmix,
      /bin/more          rmix,
      /var/log/foobar*   rwl,
      /etc/foobar        r,
   } 

  # foo's hat, bar.
   ^bar {
    /lib/ld-*.so*         mr,
    /usr/bin/bar          px,
    /var/spool/*          rwl,
   } 
}

This loads a file containing variable definitions.

The normalized path to the program that is confined.

The curly braces ({}) serve as a container for include statements, subprofiles, path entries, capability entries, and network entries.

This directive pulls in components of AppArmor profiles to simplify profiles.

Capability entry statements enable each of the 29 POSIX.1e draft capabilities.

A directive determining the kind of network access allowed to the application. For details, refer to Section 2.5, Network Access Control.

A link pair rule specifying the source and the target of a link. See Section 2.7.6, Link Pair for more information.

The curly braces ({}) make this rule apply to the path both with and without the content enclosed by the braces.

A path entry specifying what areas of the file system the program can access. The first part of a path entry specifies the absolute path of a file (including regular expression globbing) and the second part indicates permissible access modes (for example r for read, w for write, and x for execute). A whitespace of any kind (spaces or tabs) can precede pathnames or separate the pathname from the access modes. Spaces between the access mode and the trailing comma is optional. Find a comprehensive overview of the available access modes in Section 2.7, File Permission Access Modes.

This variable expands to a value that can be changed without changing the entire profile.

An owner conditional rule, granting read and write permission on files owned by the user. Refer to Section 2.7.7, Owner Conditional Rules for more information.

This entry defines a transition to the local profile /usr/bin/foobar. Find a comprehensive overview of the available execute modes in Section 2.8, Execute Modes.

A named profile transition to the profile bin_generic located in the global scope. See Section 2.8.7, Named Profile Transitions for details.

The local profile /usr/bin/foobar is defined in this section.

This section references a hat subprofile of the application. For more details on AppArmor's ChangeHat feature, refer to Section 6.0, Profiling Your Web Applications Using ChangeHat.

When a profile is created for a program, the program can access only the files, modes, and POSIX capabilities specified in the profile. These restrictions are in addition to the native Linux access controls.

Example: To gain the capability CAP_CHOWN, the program must have both access to CAP_CHOWN under conventional Linux access controls (typically, be a root-owned process) and have the capability chown in its profile. Similarly, to be able to write to the file /foo/bar the program must have both the correct user ID and mode bits set in the files attributes (see the chmod and chown man pages) and have /foo/bar w in its profile.

Attempts to violate Novell AppArmor rules are recorded in /var/log/audit/audit.log if the audit package is installed or otherwise in /var/log/messages. In many cases, Novell AppArmor rules prevent an attack from working because necessary files are not accessible and, in all cases, Novell AppArmor confinement restricts the damage that the attacker can do to the set of files permitted by Novell AppArmor.