between the access mode and the trailing comma is optional. A comprehensive
overview of the access modes available can be found in
Section 4.8, “File Permis-
sion Access Modes”
(page 69).
❾
This variable expands to a value that can be changed without changing the entire
profile.
TIP: Using Variables in Profiles
With the current AppArmor tools, variables as presented in the above example
can only be used when manually editing and maintaining a profile.
A typical example when variables come in handy are network scenarios in which
user home directories are not mounted in the standard location
/home/
username
, but under a custom location. Find the variable definitions for this
use case (
@{HOME}
and
@{HOMEDIRS}
) in the
/etc/apparmor.d/
tunables/home
file.
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 neces-
sary 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.
2.2
#include
Statements
#include
statements are directives that pull in components of other Novell AppArmor
profiles to simplify profiles. Include files fetch access permissions for programs. By
Profile Components and Syntax
21