| apparmor.d - syntax of security profiles for AppArmor. |
apparmor.d - syntax of security profiles for AppArmor.
AppArmor profiles describe mandatory access rights granted to given
programs and are fed to the AppArmor policy enforcement module using
apparmor_parser(8). This man page describes the format of the AppArmor
configuration files; see apparmor(7) for an overview of AppArmor.
The following is a BNF-style description of AppArmor policy configuration files; see below for an example AppArmor policy file. AppArmor configuration files are line-oriented; # introduces a comment, similar to shell scripting languages. The exception to this rule is that #include will include the contents of a file inline to the policy; this behaviour is modelled after cpp(1).
INCLUDE = '#include' ( ABS PATH | MAGIC PATH )
ABS PATH = '``' path '''' (the path is passed to open(2))
MAGIC PATH = '<' relative path '>' (the path is relative to /etc/apparmor.d/)
COMMENT = '#' TEXT
TEXT = any characters
PROFILE = [ COMMENT ... ] PROGRAM [ flags=(complain) ]'{' [ ( RESOURCE RULE | COMMENT | INCLUDE ) ... ] '}' [ SUBPROFILE ... ]
SUBPROFILE = [ COMMENT ... ] PROGRAMHAT '{' [ ( FILE RULE | COMMENT | INCLUDE ) ... ] '}'
PROGRAM = (non-whitespace characters except for ^, must start with '/')
PROGRAMHAT = PROGRAM '^' (non-whitespace characters; see change_hat(2) for a description of how this ``hat'' is used.)
RESOURCE RULE = ( FILE RULE | NETWORK RULE ) ','
FILE RULE = ( FILENAME | FILEGLOB ) ACCESS
FILENAME = (non-whitespace characters except for ?*[]{}^, must start with '/')
FILEGLOB = (non-whitespace characters, must start with '/', ?*[]{}^ have special meanings; see below.)
ACCESS = ( 'r' | 'w' | 'l' | 'ix' | 'ux' | 'px' ) ACCESS (not all combinations are allowed; see below.)
All resources and programs need a full path. There may be any number
of subprofiles (``hats'') in a profile, limited only by kernel memory.
Subprofile names are limited to 974 characters. Subprofiles must be in the
same file as the parent profile. Not all profiles benefit from subprofiles
--- applications must either be written or modified to use change_hat(2)
to take advantage of subprofiles. (An Apache module, mod_apparmor(5)
has been provided to use change_hat(2).)
File permission access modes consists of combinations of the following seven modes:
Allows the program to have read access to the resource. Read access is
required for shell scripts and other interpreted content, and determines
if an executing process can core dump or be attached to with ptrace(2).
(ptrace(2) is used by utilities such as strace(1), ltrace(1), and
gdb(1).)
Allows the program to have write access to the resource. Files must have this permission if they are to be unlinked (removed.)
Allows the program to execute the resource without any AppArmor profile being applied to the executed resource. Requires listing execute mode as well. Incompatible with Inherit and Discrete Profile execute entries.
This mode is useful when a confined program needs to be able to perform
a privileged operation, such as rebooting the machine. By placing the
privileged section in another executable and granting unconstrained
execution rights, it is possible to bypass the mandatory constraints
imposed on all confined processes. For more information on what is
constrained, see the apparmor(7) man page.
WARNING this should only be used in very special cases. It enables the designated child processes to be run without any AppArmor protection. Use at your own risk.
Prevent the normal AppArmor domain transition on execve(2) when the
profiled program executes the resource. Instead, the executed resource
will inherit the current profile. Incompatible with Unconstrained and
Discrete Profile execute entries.
This mode is useful when a confined program needs to call another confined program without gaining the permissions of the target's profile, or losing the permissions of the current profile. This mode is infrequently used.
This mode requires that a discrete security profile is defined for a resource executed at a AppArmor domain transition. If there is no profile defined then the access will be denied. Incompatible with Inherit and Unconstrained execute entries.
Allows the program to be able to create and remove a link with this name (including symlinks). When a link is created, the file that is being linked to MUST have the same access permissions as the link being created (with the exception that the destination does not have to have link access.) Link access is required for unlinking a file.
Comments start with # and may begin at any place within a line. The comment ends when the line ends. This is the same comment style as shell scripts.
File resources may be specified with a globbing syntax similar to that used by popular shells, such as csh(1), bash(1), zsh(1).
can substitute for any number of characters, excepting '/'
can substitute for any number of characters, including '/'
can substitute for any single character excepting '/'
will substitute for the single character a, b, or c
will substitute for the single character a, b, or c
will expand to one rule to match ab, one rule to match cd
AppArmor provides an easy abstraction mechanism to group common file access requirements; this abstraction is an extremely flexible way to grant site-specific rights and makes writing new AppArmor profiles very simple by assembling the needed building blocks for any given program.
The use of '#include' is modelled directly after cpp(1); its use will replace the '#include' statement with the specified file's contents. #include ``/absolute/path'' specifies that /absolute/path should be used. #include ``relative/path'' specifies that relative/path should be used, where the path is relative to the current working directory. #include <magic/path> is the most common usage; it will load magic/path relative to a directory specified to apparmor_parser(8). /etc/apparmor.d/ is the AppArmor default.
The supplied AppArmor profiles follow several conventions; the abstractions stored in /etc/apparmor.d/abstractions/ are some large clusters that are used in most profiles. What follows are short descriptions of how some of the abstractions are used.
includes files that should be readable in all profiles, files that should be writable in all profiles, and a single network confinement rule to ensure every domain includes network constraints.
includes file rules to allow DNS, LDAP, NIS, SMB, user and group password databases, services, and protocols lookups.
includes read and write access to the device files controlling the virtual console, sshd(8), xterm(1), etc. This abstraction is needed for many programs that interact with users.
includes write access to files used to maintain wtmp(5) and utmp(5)
databases, used with the w(1) and associated commands.
includes file access rules needed for common kerberos clients.
The abstractions stored in /etc/apparmor.d/program-chunks/ are intended for use by single programs.
References to user home directories in profiles are usually confined to abstractions stored in files with names beginning with ``user-''. There are many here suitable for customization; a few notable entries:
is a convenient place to put file access that should be allowed for
Apache change_hat(2) conventions that don't have a more specific
subprofile in Apache's profile. See also mod_apparmor(5).
An example AppArmor profile:
# a comment about foo.
/usr/bin/foo {
/bin/mount ux,
/dev/{,u}random r,
/etc/ld.so.cache r,
/etc/foo.conf r,
/etc/foo/* r,
/lib/ld-*.so* x,
/lib/lib*.so* r,
/proc/[0-9]** r,
/usr/lib/** r,
/tmp/foo.pid wr,
/tmp/foo.* lrw,
# a comment about foo's subprofile, bar.
^bar {
/lib/ld-*.so* x,
/usr/bin/bar x,
/var/spool/* rwl,
}
}
apparmor(7), apparmor_parser(8), complain(1), enforce(1), change_hat(2), mod_apparmor(5), and http://forge.novell.com/modules/xfmod/project/.
| apparmor.d - syntax of security profiles for AppArmor. |