Structure of a Profile

Profiles are simple text files in the /etc/apparmor.d directory. They consist of several parts: #include, capability entries, rules, and hats.

#include

This is the section of an AppArmor profile that refers to an include file, which mediates 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. It is good practice to select includes when suggested.

To assist you in profiling your applications, AppArmor provides three classes of #includes: abstractions, program chunks, and variables.

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, for example, base, consoles, kerberosclient, perl, user-mail, user-tmp, authentication, bash, nameservice.

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.

Using variables, you can design your profiles to be portable to different environments. Changes in the variable's content are just made in the variable definition while the profile containing the variable can remain untouched.

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.

Rules: General Options for Files and Directories

Option

File

read

r

write

w

link

l

file locking

k

file append (mutually exclusive to w)

a

Rules: Defining Execute Permissions

For executables that may be called from the confined programs, the profile creating tools ask you for an appropriate mode, which is also reflected directly in the profile itself:

Option

File

Description

Inherit

ix

Stay in the same (parent's) profile.

Profile

px

Requires that a separate profile exists for the executed program. No environment scrubbing.

Profile

Px

Requires that a separate profile exists for the executed program. Uses environment scrubbing.

Unconstrained

ux

Executes the program without a profile. Avoid running programs in unconstrained or unconfined mode for security reasons. No environment scrubbing.

Unconstrained

Ux

Executes the program without a profile. Avoid running programs in unconstrained or unconfined mode for security reasons. This mode makes use of environment scrubbing.

Allow Executable Mapping

m

allow PROT_EXEC with mmap(2) calls

WARNING: Running in ux Mode

Avoid running programs in ux mode as much as possible. A program running in ux mode is not only totally unprotected by AppArmor, but child processes inherit certain environment variables from the parent that might influence the child's execution behavior and create possible security risks.

For more information about the different file execute modes, refer to the apparmor.d(5) man page. For more information about setgid and setuid environment scrubbing, refer to the ld.so(8) man page.

Network Access Control

AppArmor provides network access mediation based on network domain and type:

/bin/ping {
network inet dgram,
network inet raw,
...
}

The example would allow IPv4 network access of the datagram and raw type for the ping command. For details on the network rule syntax, refer to the Novell AppArmor Administration Guide.

Rules: Paths and Globbing

AppArmor supports explicit handling of directories. 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 ([^/]).

To spare users from specifying similar paths all over again, AppArmor supports basic globbing:

Glob

Description

*

Substitutes for any number of characters, except /.

**

Substitutes for any number of characters, including /.

?

Substitutes for any single character, except /.

[ abc ]

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

[ a-c ]

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

{ ab,cd }

Expand to one rule to match ab and another to match cd.

[ ^a ]

Substitutes for any character except a.

WARNING: Updating Profiles to AppArmor 2.1

If you have been using prior versions of AppArmor, many of the old profiles may trigger unexpected behavior of the profiled applications. In this case, update your profiles as outlined in the Troubleshooting section of the Novell AppArmor Administration Guide.

Hats

An AppArmor profile represents a security policy for an individual program instance or process. It applies to an executable program, but if a portion of the program needs different access permissions than other portions, the program can change hats to use a different security context, distinctive from the access of the main program. This is known as a hat or subprofile.

A profile can have an arbitrary number of subprofiles, but there are only two levels: a subprofile cannot have further sub-subprofiles.

The AppArmor ChangeHat feature can be used by applications to access hats or subprofiles during execution. Currently the packages apache2-mod_apparmor and tomcat_apparmor utilize ChangeHat to provide sub-process confinement for the Apache Web server and the Tomcat servlet container.