 apparmor.d - syntax of security profiles for AppArmor. 
	
#nameNAME 	
#descriptionDESCRIPTION 	
#formatFORMAT 	
		
#access_modesAccess Modes 		
#access_modes_detailsAccess Modes Details 		
#commentsComments 		
#globbingGlobbing 		
#network_rulesNetwork Rules 		
#_include_mechanism#include mechanism 	
	
#exampleEXAMPLE 	
#filesFILES 	
#see_alsoSEE ALSO 
NAME 
apparmor.d - syntax of security profiles for AppArmor.
DESCRIPTION 
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.
FORMAT 
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).)
Access Modes 
File permission access modes consists of combinations of the following
seven modes:
r 	- read w 	- write px 	- discrete profile execute ux 	- unconstrained execute ix	- inherit execute l 	- link 
Access Modes Details 
Read mode 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).)
Write mode Allows the program to have write access to the resource. Files must have
this permission if they are to be unlinked (removed.)
Unconstrained execute mode 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.
Inherit execute mode 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.
Discrete Profile execute mode 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.
Link mode 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 
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.
Globbing 
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 '/'
[abc] will substitute for the single character a, b, or c
[a-c] will substitute for the single character a, b, or c
{ab,cd} will expand to one rule to match ab, one rule to match cd
#include mechanism 
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.
abstractions/base 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.
abstractions/nameservice includes file rules to allow DNS, LDAP, NIS, SMB, user and group password
databases, services, and protocols lookups.
abstractions/consoles 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.
abstractions/wutmp includes write access to files used to maintain wtmp(5) and utmp(5)databases, used with the 
w(1) and associated commands.
abstractions/kerberosclient 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:
program-chunks/apache-default-uri 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).
EXAMPLE 
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,
          }
        }
FILES 
/etc/init.d/boot.apparmor /etc/apparmor.d/ /usr/share/vim/current/syntax/apparmor.vim 
SEE ALSO 
apparmor(7), apparmor_parser(8), complain(1),
enforce(1), change_hat(2), mod_apparmor(5), and
http://forge.novell.com/modules/xfmod/project/?apparmorhttp://forge.novell.com/modules/xfmod/project/ .
 apparmor.d - syntax of security profiles for AppArmor. 