2.1 Breaking a Novell AppArmor Profile into Its Parts

Novell AppArmor profile components are called Novell AppArmor rules. Currently there are three main types of Novell AppArmor rules, path entries, capability entries, and network entries. Path entries specify what the process can access in the file system and capability entries provide a more fine-grained control over what a confined process is allowed to do through other system calls that require privileges. Includes are a type of meta rule or directives that pull in path and capability entries from other files.

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,

   /bin/mount          ux,
   /dev/{,u}random     r,
   /etc/ld.so.cache    r,
   /etc/foo.conf       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,

  # a comment about foo's subprofile, 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.1.1, Network Access Control.

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 (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.1.3, File Permission Access Modes.

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

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

HINT: Using Variables in Profiles

With the current AppArmor tools, variables as presented in the above example can only be used when manually editing and maintaining a profile.

A typical example when variables come in handy are network scenarios in which user home directories are not mounted in the standard location /home/username, but under a custom location. Find the variable definitions for this use case (@{HOME} and @{HOMEDIRS}) in the /etc/apparmor.d/tunables/home file.

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.

2.1.1 Network Access Control

AppArmor allows mediation of network access based on the address type and family. The following illustrates the network access rule syntax: 

network [[<domain>][<type>][<protocol>]]

Supported domains: inet, ax25, ipx, appletalk, netrom, bridge, x25, inet6, rose, netbeui, security, key, packet, ash, econet, atmsvc, sna, irda, pppox, wanpipe, bluetooth

Supported types: stream, dgram, seqpacket, rdm, raw, packet

Supported protocols: tcp, udp, icmp

The AppArmor tools support only family and type specification. The AppArmor module emits only network domain type in access denied messages. And only these are output by the profile generation tools, both YaST and command line.

The following examples illustrate possible network-related rules to be used in AppArmor profiles. Note that the syntax of the two last ones is not currently supported by the AppArmor tools. 

network,
network inet,
network inet6,
network inet stream,
network inet tcp,
network tcp,

Allow all networking. No restrictions applied with regards to domain, type, or protocol.

Allow general use of IPv4 networking.

Allow general use of IPv6 networking.

Allow the use of IPv4 TCP networking.

Allow the use of IPv4 TCP networking, paraphrasing the rule above.

Allow the use of both IPv4 and IPv6 TCP networking.

2.1.2 Paths and Globbing

AppArmor explicitly distinguishes directory path names from file path names. Use a trailing / for any directory path that needs to be explicitly distinguished:

/some/random/example/* r

Allow read access to files in the /some/random/example directory.

/some/random/example/ r

Allow read access to the directory only.

/some/**/ r

Give read access to any directories below /some.

/some/random/example/** r

Give read access to files and directories under /some/random/example.

/some/random/example/**[^/] r

Give read access to files under /some/random/example. Explicitly exclude directories ([^/]).

Globbing (or regular expression matching) is when you modify the directory path using wild cards to include a group of files or subdirectories. File resources can be specified with a globbing syntax similar to that used by popular shells, such as csh, Bash, and zsh.

*

Substitutes for any number of any characters, except /.

Example: An arbitrary number of file path elements.

**

Substitutes for any number of characters, including /.

Example: An arbitrary number of path elements, including entire directories.

?

Substitutes for any single character, except /.

[abc]

Substitutes for the single character a, b, or c.

Example: a rule that matches /home[01]/*/.plan allows a program to access .plan files for users in both /home0 and /home1.

[a-c]

Substitutes for the single character a, b, or c.

{ab,cd}

Expands to one rule to match ab and one rule to match cd.

Example: a rule that matches /{usr,www}/pages/** grants access to Web pages in both /usr/pages and /www/pages.

[ ^a ]

Substitutes for any character except a.

2.1.3 File Permission Access Modes

File permission access modes consist of combinations of the following eleven modes:

r

Read mode

w

Write mode (mutually exclusive to a)

a

Append mode (mutually exclusive to w)

k

File locking mode

px

Discrete profile execute mode

Px

Discrete profile execute mode—clean exec

ux

Unconstrained execute mode

Ux

Unconstrained execute mode—clean exec

ix

Inherit execute mode

m

Allow PROT_EXEC with mmap(2) calls

l

Link mode

Read Mode (r)

Allows the program to have read access to the resource. Read access is required for shell scripts and other interpreted content and determines if an executing process can core dump or be attached to with ptrace(2) (ptrace(2) is used by utilities like strace(1), ltrace(1), and gdb(1)).

Write Mode (w)

Allows the program to have write access to the resource. Files must have this permission if they are to be unlinked (removed).

Append Mode (a)

Allows a program to write to the end of a file. In contrast to the w mode, the append mode does not include the ability to overwrite data, to rename, or to remove a file. The append permission is typically used with applications who need to be able to write to log files, but which should not be able to manipulate any existing data in the log files. As the append permission is just a subset of the permissions associated with the write mode, the w and a permission flags cannot be used together and are mutually exclusive.

File Locking Mode (k)

The application can take file locks. Former versions of AppArmor allowed files to be locked if an application had access to them. By using a separate file locking mode, AppArmor makes sure locking is restricted only to those files which need file locking and tightens security as locking can be used in several denial of service attack scenarios.

Discrete Profile Execute Mode (px)

This mode requires that a discrete security profile is defined for a resource executed at an AppArmor domain transition. If there is no profile defined, the access is denied.

WARNING: Using the Discrete Profile Execute Mode

px does not scrub the environment of variables such as LD_PRELOAD. As a result, the calling domain may have an undue amount of influence over the called item.

Incompatible with Ux, ux, Px, and ix.

Discrete Profile Execute Mode (Px)—Clean Exec

Px allows the named program to run in px mode, but AppArmor invokes the Linux kernel's unsafe_exec routines to scrub the environment, similar to setuid programs. See ld.so(8) for some information about setuid and setgid environment scrubbing.

Incompatible with Ux, ux, px, and ix.

Unconstrained Execute Mode (ux)

Allows the program to execute the resource without any AppArmor profile applied to the executed resource. Requires listing execute mode as well.

This mode is useful when a confined program needs to be able to perform a privileged operation, such as rebooting the machine. By placing the privileged section in another executable and granting unconstrained execution rights, it is possible to bypass the mandatory constraints imposed on all confined processes. For more information about what is constrained, see the apparmor(7) man page.

WARNING: Using Unconstrained Execute Mode (ux)

Use ux only in very special cases. It enables the designated child processes to be run without any AppArmor protection. ux does not scrub the environment of variables such as LD_PRELOAD. As a result, the calling domain may have an undue amount of influence over the called resource. Use this mode only if the child absolutely must be run unconfined and LD_PRELOAD must be used. Any profile using this mode provides negligible security. Use at your own risk.

This mode is incompatible with Ux, px, Px, and ix.

Unconstrained Execute Mode (Ux)—Clean Exec

Ux allows the named program to run in ux mode, but AppArmor invokes the Linux kernel's unsafe_exec routines to scrub the environment, similar to setuid programs. See ld.so(8) for some information about setuid and setgid environment scrubbing.

WARNING: Using Unconstrained Execute Mode (Ux)

Use Ux only in very special cases. It enables the designated child processes to run without any AppArmor protection. Use this mode only if the child absolutely must be run unconfined. Use at your own risk.

Incompatible with ux, px, Px, and ix.

Inherit Execute Mode (ix)

ix prevents the normal AppArmor domain transition on execve(2) when the profiled program executes the named program. Instead, the executed resource inherits the current profile.

This mode is useful when a confined program needs to call another confined program without gaining the permissions of the target's profile or losing the permissions of the current profile. There is no version to scrub the environment because ix executions do not change privileges.

Incompatible with Ux, ux, Px, and px. Implies m.

Allow Executable Mapping (m)

This mode allows a file to be mapped into memory using mmap(2)'s PROT_EXEC flag. This flag marks the pages executable. It is used on some architectures to provide nonexecutable data pages, which can complicate exploit attempts. AppArmor uses this mode to limit which files a well-behaved program (or all programs on architectures that enforce nonexecutable memory access controls) may use as libraries, to limit the effect of invalid -L flags given to ld(1) and LD_PRELOAD, LD_LIBRARY_PATH, given to ld.so(8).

Link Mode

The link mode mediates access to hard links. When a link is created, the target file must have the same access permissions as the link created (with the exception that the destination does not need link access).

When choosing one of the Ux or Px file permission access modes, take into account that the following environment variables are removed from the environment before the child process inherits it. As a consequence, applications or processes relying on any of these variables do not work anymore if the profile applied to them carries Ux or Px flags:

  • GCONV_PATH

  • GETCONF_DIR

  • HOSTALIASES

  • LD_AUDIT

  • LD_DEBUG

  • LD_DEBUG_OUTPUT

  • LD_DYNAMIC_WEAK

  • LD_LIBRARY_PATH

  • LD_ORIGIN_PATH

  • LD_PRELOAD

  • LD_PROFILE

  • LD_SHOW_AUXV

  • LD_USE_LOAD_BIAS

  • LOCALDOMAIN

  • LOCPATH

  • MALLOC_TRACE

  • NLSPATH

  • RESOLV_HOST_CONF

  • RES_OPTIONS

  • TMPDIR

  • TZDIR