To assist you in proling your applications, AppArmor pro-
vides three classes of #includes: abstractions, program
chunks, and variables.
Abstractions are #includes that are grouped by common
application tasks. These tasks include access to authentica-
tion 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 specic 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 proles to be portable
to different environments. Changes in the variable's content
are just made in the variable denition while the prole
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 dened
in the capabilities(7) man page.
Rules: General Options for Files and
Directories
FileOption
rread
wwrite
llink
Rules: Dening Execute Permissions
For executables that may be called from the conned pro-
grams, the prole creating tools ask you for an appropriate
mode, which is also reected directly in the prole itself:
DescriptionFileOption
Stay in the same (parent's) prole.ixInherit
Requires that a separate prole ex-
ists for the executed program. No
environment scrubbing.
pxProle
Requires that a separate prole ex-
ists for the executed program. Uses
environment scrubbing.
PxProle
Executes the program without a
prole. Avoid running programs in
uxUncon-
strained
unconstrained or unconned mode
for security reasons. No environ-
ment scrubbing.
Executes the program without a
prole. Avoid running programs in
UxUncon-
strained
unconstrained or unconned mode
DescriptionFileOption
for security reasons. This mode
makes use of environment scrub-
bing.
allow PROT_EXEC with mmap(2)
calls
mAllow Exe-
cutable Map-
ping
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 process-
es inherit certain environment variables from the
parent that might inuence the child's execution
behavior and create possible security risks.
For more information about the different le 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.
Rules: Paths and Globbing
DescriptionGlob
Substitutes for any number of characters,
except /.
*
Substitutes for any number of characters,
including /.
**
Substitutes for any single character, ex-
cept /.
?
Substitutes for the single character a,b,
or c.
[ abc ]
Substitutes for the single character a,b,
or c.
[ a-c ]
Expand to one rule to match ab and an-
other to match cd.
{ ab,cd }
Hats
An AppArmor prole represents a security policy for an
individual program instance or process. It applies to an ex-
ecutable program, but if a portion of the program needs
different access permissions than other portions, the pro-
gram can “change hats” to use a different security context,
distinctive from the access of the main program. This is
known as a hat or subprole.
A prole can have an arbitrary number of subproles, but
there are only two levels: a subprole cannot have further
sub-subproles.
The AppArmor ChangeHat feature can be used by applica-
tions to access hats or subproles during execution. Current-
ly the packages apache2-mod_apparmor and tom-
3