Profiles are simple text files in the
/etc/apparmor.d
directory. They consist of several
parts: #include, capability entries, rules, and “hats.”
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 tunables.
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.
Tunables are global variable definitions. When used in a profile, these variables expand to a value that can be changed without changing the entire profile. Therefore your profiles become portable to different environments.
Local variables are defined at the head of a profile. Use local variables to create shortcuts for paths, for example to provide the base for a chrooted path:
@{CHROOT_BASE}=/tmp/foo /sbin/syslog-ng { ... # chrooted applications @{CHROOT_BASE}/var/lib/*/dev/log w, @{CHROOT_BASE}/var/log/** w, ... }
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 (↑Novell AppArmor Administration Guide).
Capabilities statements are simply the word “capability” followed by the name of the POSIX.1e capability as defined in the capabilities(7) man page.
Option |
File |
---|---|
read |
|
write |
|
link |
|
file locking |
|
file append (mutually exclusive to |
|
The link mode grants permission to create links to arbitrary files, provided the link has a subset of the permissions granted by the target (subset permission test). By specifying origin and destination, the link pair rule provides greater control over how hard links are created. Link pair rules by default do not enforce the link subset permission test that the standard rules link permission requires. To force the rule to require the test the subset keyword is used. The following rules are equivalent:
/link l, link subset /link -> /**,
AppArmor provides deny
rules which are standard rules
but with the keyword deny
prepended. They are used to
remember known rejects, and quiet them so the reject messages don't fill
up the log files. For more information see the
Novell AppArmor Administration Guide (↑Novell AppArmor Administration Guide).
The file rules can be extended so that they can be conditional upon the
the user being the owner of the file. by prepending the keyword
owner
to the rule. Owner conditional rules accumulate
just as regular file rules and are considered a subset of regular file
rules. If a regular file rule overlaps with an owner conditional file
rule, the resultant permissions will be that of the regular file rule.
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 |
|
Stay in the same (parent's) profile. |
Profile |
|
Requires that a separate profile exists for the executed program.
Use |
Local profile |
|
Requires that a local profile exists for the executed program. Use
|
Unconstrained |
|
Executes the program without a profile. Avoid running programs in
unconstrained or unconfined mode for security reasons. Use
|
Allow Executable Mapping |
|
allow |
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.
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 |
|
Substitutes for the single character |
|
Substitutes for the single character |
|
Expand to one rule to match |
|
Substitutes for any character except |
Updating Profiles to AppArmor 2.3 | |
---|---|
If you have been using versions of AppArmor prior to 2.1, 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 (↑Novell AppArmor Administration Guide). |
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 hats, but there are only two levels: a hat cannot have further hats.
The AppArmor ChangeHat feature can be used by applications to access hats
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.