Contents
You are ready to build Novell AppArmor profiles after you select the programs to profile. To do so, it is important to understand the components and syntax of profiles. AppArmor profiles contain several building blocks that help build simple and reusable profile code:
#include
Files
#include
statements are used to pull in parts of
other AppArmor profiles to simplify the structure of new profiles.
Abstractions are #include
statements grouped by
common application tasks.
Program chunks are #include
statements that contain
chunks of profiles that are specific to program suites.
Capability entries are profile entries for any of the POSIX.1e Linux capabilities allowing a fine-grained control over what a confined process is allowed to do through system calls that require privileges.
Network Access Control Entries mediate network access based on the address type and family.
Local variables define shortcuts for paths.
File Access Control Entries specify the set of files an application can access.
rlimit entries set and control an application's resource limits.
For help determining the programs to profile, refer to Section 1.2, “Determining Programs to Immunize”. To start building AppArmor profiles with YaST, proceed to Chapter 4, Building and Managing Profiles with YaST. To build profiles using the AppArmor command line interface, proceed to Chapter 5, Building Profiles from the Command Line.
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, link /etc/sysconfig/foo -> /etc/foo.conf, /bin/mount ux, /dev/{,u}random r, /etc/ld.so.cache 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, owner /shared/foo/** rw, /usr/bin/foobar cx, /bin/** px -> bin_generic, # a comment about foo's local (children)profile for /usr/bin/foobar. profile /usr/bin/foobar { /bin/bash rmix, /bin/cat rmix, /bin/more rmix, /var/log/foobar* rwl, /etc/foobar r, } # foo's hat, 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 ( | |
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.5, “Network Access Control”. | |
A link pair rule specifying the source and the target of a link. See Section 2.7.6, “Link Pair” for more information. | |
The curly 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 (for example | |
This variable expands to a value that can be changed without changing the entire profile. | |
An owner conditional rule, granting read and write permission on files owned by the user. Refer to Section 2.7.7, “Owner Conditional Rules” for more information. | |
This entry defines a transition to the local profile
| |
A named profile transition to the profile bin_generic located in the global scope. See Section 2.8.7, “Named Profile Transitions” for details. | |
The local profile | |
This section references a “hat” subprofile of the application. For more details on AppArmor's ChangeHat feature, refer to Chapter 6, Profiling Your Web Applications Using ChangeHat. |
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.