Chapter 3. Building Novell AppArmor Profiles

Contents

3.1. Profile Components and Syntax
3.2. Building and Managing Novell AppArmor Profiles
3.3. Building Novell AppArmor Profiles with the YaST GUI
3.4. Building Novell AppArmor Profiles Using the Command Line Interface
3.5. Two Methods of Profiling
3.6. Pathnames and Globbing
3.7. File Permission Access Modes

This chapter explains how to build and manage Novell® AppArmor profiles. You are ready to build Novell AppArmor profiles after you select the programs to profile. For help with this, refer to Chapter 2, Selecting Programs to Immunize (↑Novell AppArmor 2.0 Administration Guide).


3.1. Profile Components and Syntax

This section details the syntax or makeup of Novell AppArmor profiles. An example illustrating this syntax is presented in Section 3.1.1, “Breaking a Novell AppArmor Profile into Its Parts” (↑Novell AppArmor 2.0 Administration Guide).

3.1.1. Breaking a Novell AppArmor Profile into Its Parts

Novell AppArmor profile components are called Novell AppArmor rules. Currently there are two main types of Novell AppArmor rules, path entries and capability 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. Consider, for example, the following profile for the program /sbin/klogd:

# profile to confine klogd1
/sbin/klogd 2
{3
#include <abstractions/base>4
  capability sys_admin,5
  /boot/* r6,
  /proc/kmsg r,
  /sbin/klogd r,
  /var/run/klogd.pid lw,
}
1

A comment naming the program that is confined by this profile. Always precede comments like this with the # sign.

2

The absolute path to the program that is confined.

3

The curly braces {} serve as a container for include statements of other profiles as well as for path and capability entries.

4

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

5

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

6

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 white space of any kind (spaces or tabs) can precede pathnames or separate the pathname from the access modes. White space between the access mode and the trailing comma is optional.

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 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 syslog. 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.

3.1.2. #include

#include statements are directives that pull in components of other Novell AppArmor profiles to simplify profiles. Include files fetch access permissions for programs. By using an include, you can give the program access to directory paths or files that are also required by other programs. Using includes can reduce the size of a profile.

By default, the #include statement appends /etc/apparmor.d/, which is where it expects to find the include file, to the beginning of the pathname. Unlike other profile statements (but similar to C programs), #include lines do not end with a comma.

To assist you in profiling your applications, Novell AppArmor provides two classes of #includes, abstractions, and program chunks.

3.1.2.1. Abstractions

Abstractions are #includes that are grouped by common application tasks. These tasks include access to authentication mechanisms, access to name service routines, common graphics requirements, and system accounting. Files listed in these abstractions are specific to the named task; programs that require one of these files usually require some of the other files listed in the abstraction file (depending on the local configuration as well as the specific requirements of the program). Abstractions can be found in /etc/apparmor.d/abstractions/.

3.1.2.2. Program Chunks

Program chunks are access controls for specific programs that a system administrator might want to control based on local site policy. Each chunk is used by a single program. These are provided to ease local-site modifications to policy and updates to policy provided by Novell AppArmor. Administrators can modify policy in these files to suit their own needs and leave the program profiles unmodified, simplifying the task of merging policy updates from Novell AppArmor into enforced policy at each site.

The access restrictions in the program chunks are typically very liberal and are designed to allow your users access to their files in the least intrusive way possible while still allowing system resources to be protected. An exception to this rule is the postfix* series of program chunks. These profiles are used to help abstract the location of the postfix binaries. You probably do not want to reduce the permissions in the postfix* series. Program chunks can be found in /etc/apparmor.d/program-chunks/.

3.1.3. Capability Entries (POSIX.1e)

Capabilities statements are simply the word “capability” followed by the name of the POSIX.1e capability as defined in the capabilities(7) man page.