{ "mode": "man", "parameter": "APPARMOR.D", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/APPARMOR.D/5/json", "generated": "2026-10-22T11:53:46Z", "sections": { "NAME": { "content": "apparmor.d - syntax of security profiles for AppArmor.\n", "subsections": [] }, "DESCRIPTION": { "content": "AppArmor profiles describe mandatory access rights granted to given programs and are fed to\nthe AppArmor policy enforcement module using apparmorparser(8). This man page describes the\nformat of the AppArmor configuration files; see apparmor(7) for an overview of AppArmor.\n", "subsections": [] }, "FORMAT": { "content": "AppArmor policy is written in a declarative language, in which the order of rules within a\ngiven section or block does not matter. Policy is by convention written so that it is\ncontained in multiple files, but this is not a requirement. It could just as easily be\nwritten in a single file. The policy language is compiled to a architecture independent\nbinary format that is loaded into the kernel for enforcement.\n\nThe base unit of AppArmor confinement is the profile. It contains a set of rules which are\nenforced when the profile is associated with a running program. The rules within the profile\nprovide a whitelist of different permission that are allowed, along with a few other special\nrules.\n\nThe text in AppArmor policy is split into two sections, the preamble and the profile\ndefinitions. The preamble must occur at the head of the file and once profile definitions\nbegin, no more preamble rules are allowed (even in files that are included into the profile).\nWhen AppArmor policy (set of profiles) is split across multiple files, each file can have its\nown preamble section, which may be the same or different from other files preamble. Files\nincluded within a profile section can not have a preamble section.\n\nThe following is a BNF-style description of AppArmor policy configuration files; see below\nfor an example AppArmor policy file. AppArmor configuration files are line-oriented; #\nintroduces a comment, similar to shell scripting languages. The exception to this rule is\nthat #include will include the contents of a file inline to the policy; this behaviour is\nmodelled after cpp(1).\n\nPROFILE FILE = ( [ PREAMBLE ] [ PROFILE ] )*\n\nPREAMBLE = ( COMMENT | VARIABLE ASSIGNMENT | ALIAS RULE | INCLUDE | ABI )*\nVariable assignment and alias rules must come before the profile.\n\nVARIABLE ASSIGNMENT = VARIABLE ('=' | '+=') (space separated values)\n\nVARIABLE = '@{' ALPHA [ ( ALPHANUMERIC | '' ) ... ] '}'\n\nALIAS RULE = 'alias' ABS PATH '->' REWRITTEN ABS PATH ','\n\nINCLUDE = ( '#include' | 'include' ) [ 'if exists' ] ( ABS PATH | MAGIC PATH )\n\nABI = ( 'abi' ) ( ABS PATH | MAGIC PATH ) ','\n\nABS PATH = '\"' path '\"' (the path is passed to open(2))\n\nMAGIC PATH = '<' relative path '>'\nThe path is relative to /etc/apparmor.d/.\n\nCOMMENT = '#' TEXT [ '\\r' ] '\\n'\n\nTEXT = any characters\n\nPROFILE = ( PROFILE HEAD ) [ ATTACHMENT SPECIFICATION ] [ PROFILE FLAG CONDS ] '{' (\nRULES )* '}'\n\nPROFILE HEAD = [ 'profile' ] FILEGLOB | 'profile' PROFILE NAME\n\nPROFILE NAME ( UNQUOTED PROFILE NAME | QUOTED PROFILE NAME )\n\nQUOTED PROFILE NAME = '\"' UNQUOTED PROFILE NAME '\"'\n\nUNQUOTED PROFILE NAME = (must start with alphanumeric character (after variable\nexpansion), or '/' AARE have special meanings; see below. May include VARIABLE. Rules\nwith embedded spaces or tabs must be quoted.)\n\nATTACHMENT SPECIFICATION = [ PROFILEEXECCOND ] [ PROFILE XATTR CONDS ]\n\nPROFILEEXECCOND = FILEGLOB\n\nPROFILE XATTR CONDS = [ 'xattrs=' ] '(' comma or white space separated list of PROFILE\nXATTR ')'\n\nPROFILE XATTR = extended attribute name '=' XATTR VALUE FILEGLOB\n\nXATTR VALUE FILEGLOB = FILEGLOB\n\nPROFILE FLAG CONDS = [ 'flags=' ] '(' comma or white space separated list of PROFILE\nFLAGS ')'\n\nPROFILE FLAGS = PROFILE MODE | AUDITMODE | 'mediatedeleted' | 'attachdisconnected' |\n'attachdisconneced.path='ABS PATH | 'chrootrelative' | 'debug' | 'interruptible' |\n'kill.signal='SIGNAL\n\nPROFILE MODE = 'enforce' | 'complain' | 'kill' | 'defaultallow' | 'unconfined' |\n'prompt'\n\nAUDIT MODE = 'audit'\n\nRULES = [ ( LINE RULES | COMMA RULES ',' | BLOCK RULES )\n\nLINE RULES = ( COMMENT | INCLUDE ) [ '\\r' ] '\\n'\n\nCOMMA RULES = ( CAPABILITY RULE | NETWORK RULE | MOUNT RULE | PIVOT ROOT RULE | UNIX RULE\n| FILE RULE | LINK RULE | CHANGEPROFILE RULE | RLIMIT RULE | DBUS RULE | MQUEUE RULE |\nIOURING RULE | USERNS RULE | ALL RULE)\n\nBLOCK RULES = ( SUBPROFILE | HAT | QUALIFIER BLOCK )\n\nSUBPROFILE = 'profile' PROFILE NAME [ ATTACHMENT SPECIFICATION ] [ PROFILE FLAG CONDS ]\n'{' ( RULES )* '}'\n\nHAT = ('hat' | '^') HATNAME [ PROFILE FLAG CONDS ] '{' ( RULES )* '}'\n\nHATNAME = (must start with alphanumeric character. See aachangehat(2) for a description\nof how this \"hat\" is used. If '^' is used to start a hat then there is no space between\nthe '^' and HATNAME)\n\nQUALIFIER BLOCK = QUALIFIERS BLOCK\n\nACCESS TYPE = ( 'allow' | 'deny' )\n\nQUALIFIERS = [ 'audit' ] [ ACCESS TYPE ]\n\nCAPABILITY RULE = [ QUALIFIERS ] 'capability' [ CAPABILITY LIST ]\n\nCAPABILITY LIST = ( CAPABILITY )+\n\nCAPABILITY = (lowercase capability name without 'CAP' prefix; see capabilities(7))\n\nNETWORK RULE = [ QUALIFIERS ] 'network' [ NETWORK ACCESS EXPR ] [ DOMAIN ] [ TYPE |\nPROTOCOL ] [ NETWORK LOCAL EXPR ] [ NETWORK PEER EXPR ]\n\nNETWORK ACCESS EXPR = ( NETWORK ACCESS | NETWORK ACCESS LIST )\n\nNETWORK ACCESS = ( 'create' | 'bind' | 'listen' | 'accept' | 'connect' | 'shutdown' |\n'getattr' | 'setattr' | 'getopt' | 'setopt' | 'send' | 'receive' | 'r' | 'w' | 'rw' )\nSome access modes are incompatible with some rules.\n\nNETWORK ACCESS LIST = '(' NETWORK ACCESS ( [','] NETWORK ACCESS )* ')'\n\nDOMAIN = ( 'unix' | 'inet' | 'ax25' | 'ipx' | 'appletalk' | 'netrom' | 'bridge' |\n'atmpvc' | 'x25' | 'inet6' | 'rose' | 'netbeui' | 'security' | 'key' | 'netlink' |\n'packet' | 'ash' | 'econet' | 'atmsvc' | 'rds' | 'sna' | 'irda' | 'pppox' | 'wanpipe' |\n'llc' | 'ib' | 'mpls' | 'can' | 'tipc' | 'bluetooth' | 'iucv' | 'rxrpc' | 'isdn' |\n'phonet' | 'ieee802154' | 'caif' | 'alg' | 'nfc' | 'vsock' | 'kcm' | 'qipcrtr' | 'smc' |\n'xdp' | 'mctp' ) ','\n\nTYPE = ( 'stream' | 'dgram' | 'seqpacket' | 'rdm' | 'raw' | 'packet' )\n\nPROTOCOL = ( 'tcp' | 'udp' | 'icmp' )\n\nNETWORK LOCAL EXPR = ( NETWORK IP COND | NETWORK PORT COND )*\nEach cond can appear at most once.\n\nNETWORK PEER EXPR = 'peer' '=' '(' ( NETWORK IP COND | NETWORK PORT COND )+ ')'\nEach cond can appear at most once.\n\nNETWORK IP COND = 'ip' '=' ( 'none' | NETWORK IPV4 | NETWORK IPV6 )\n\nNETWORK PORT COND = 'port' '=' ( NETWORK PORT )\n\nNETWORK IPV4 = IPv4, represented by four 8-bit decimal numbers separated by '.'\n\nNETWORK IPV6 = IPv6, represented by eight groups of four hexadecimal numbers separated by\n':'. Shortened representation of contiguous zeros is allowed by using '::'\n\nNETWORK PORT = 16-bit number ranging from 0 to 65535\n\nMOUNT RULE = ( MOUNT | REMOUNT | UMOUNT )\n\nMOUNT = [ QUALIFIERS ] 'mount' [ MOUNT CONDITIONS ] [ SOURCE FILEGLOB ] [ '->' [\nMOUNTPOINT FILEGLOB ]\n\nREMOUNT = [ QUALIFIERS ] 'remount' [ MOUNT CONDITIONS ] MOUNTPOINT FILEGLOB\n\nUMOUNT = [ QUALIFIERS ] 'umount' [ MOUNT CONDITIONS ] MOUNTPOINT FILEGLOB\n\nMOUNT CONDITIONS = [ ( 'fstype' | 'vfstype' ) ( '=' | 'in' ) MOUNT FSTYPE EXPRESSION ] [\n'options' ( '=' | 'in' ) MOUNT FLAGS EXPRESSION ]\n\nMOUNT FSTYPE EXPRESSION = ( MOUNT FSTYPE LIST | MOUNT EXPRESSION )\n\nMOUNT FSTYPE LIST = Comma separated list of valid filesystem and virtual filesystem types\n(eg ext4, debugfs, devfs, etc)\n\nMOUNT FLAGS EXPRESSION = ( MOUNT FLAGS LIST | MOUNT EXPRESSION )\n\nMOUNT FLAGS LIST = Comma separated list of MOUNT FLAGS.\n\nMOUNT FLAGS = ( 'ro' | 'rw' | 'nosuid' | 'suid' | 'nodev' | 'dev' | 'noexec' | 'exec' |\n'sync' | 'async' | 'remount' | 'mand' | 'nomand' | 'dirsync' | 'noatime' | 'atime' |\n'nodiratime' | 'diratime' | 'bind' | 'rbind' | 'move' | 'verbose' | 'silent' | 'loud' |\n'acl' | 'noacl' | 'unbindable' | 'runbindable' | 'private' | 'rprivate' | 'slave' |\n'rslave' | 'shared' | 'rshared' | 'relatime' | 'norelatime' | 'iversion' | 'noiversion' |\n'strictatime' | 'nostrictatime' | 'lazytime' | 'nolazytime' | 'nouser' | 'user' |\n'symfollow' | 'nosymfollow' )\n\nMOUNT EXPRESSION = ( ALPHANUMERIC | AARE ) ...\n\nMQUEUERULE = [ QUALIFIERS ] 'mqueue' [ MQUEUE ACCESS PERMISSIONS ] [ MQUEUE TYPE ] [\nMQUEUE LABEL ] [ MQUEUE NAME ]\n\nMQUEUE ACCESS PERMISSIONS = MQUEUE ACCESS | MQUEUE ACCESS LIST\n\nMQUEUE ACCESS LIST = '(' Comma or space separated list of MQUEUE ACCESS ')'\n\nMQUEUE ACCESS = ( 'r' | 'w' | 'rw' | 'read' | 'write' | 'create' | 'open' | 'delete' |\n'getattr' | 'setattr' )\n\nMQUEUE TYPE = 'type' '=' ( 'posix' | 'sysv' )\n\nMQUEUE LABEL = 'label' '=' '(' '\"' AARE '\"' | AARE ')'\n\nMQUEUE NAME = AARE\n\nUSERNS RULE = [ QUALIFIERS ] 'userns' [ USERNS ACCESS PERMISSIONS ]\n\nUSERNS ACCESS PERMISSIONS = ( 'create' )\n\nIOURING RULE = [ QUALIFIERS ] 'iouring' [ IOURING ACCESS PERMISSIONS [ IOURING LABEL\n]\n\nIOURING ACCESS PERMISSIONS = ( 'sqpoll' | 'overridecreds' )\n\nIOURING LABEL = 'label' '=' '(' '\"' AARE '\"' | AARE ')'\n\nPIVOT ROOT RULE = [ QUALIFIERS ] pivotroot [ oldroot=OLD PUT FILEGLOB ] [ NEW ROOT\nFILEGLOB ] [ '->' PROFILE NAME ]\n\nSOURCE FILEGLOB = FILEGLOB\n\nMOUNTPOINT FILEGLOB = FILEGLOB\n\nOLD PUT FILEGLOB = FILEGLOB\n\nPTRACERULE = [ QUALIFIERS ] 'ptrace' [ PTRACE ACCESS PERMISSIONS ] [ PTRACE PEER ]\n\nPTRACE ACCESS PERMISSIONS = PTRACE ACCESS | PTRACE ACCESS LIST\n\nPTRACE ACCESS LIST = '(' Comma or space separated list of PTRACE ACCESS ')'\n\nPTRACE ACCESS = ( 'r' | 'w' | 'rw' | 'read' | 'readby' | 'trace' | 'tracedby' )\n\nPTRACE PEER = 'peer' '=' AARE\n\nSIGNALRULE = [ QUALIFIERS ] 'signal' [ SIGNAL ACCESS PERMISSIONS ] [ SIGNAL SET ] [\nSIGNAL PEER ]\n\nSIGNAL ACCESS PERMISSIONS = SIGNAL ACCESS | SIGNAL ACCESS LIST\n\nSIGNAL ACCESS LIST = '(' Comma or space separated list of SIGNAL ACCESS ')'\n\nSIGNAL ACCESS = ( 'r' | 'w' | 'rw' | 'read' | 'write' | 'send' | 'receive' )\n\nSIGNAL SET = 'set' '=' '(' SIGNAL LIST ')'\n\nSIGNAL LIST = Comma or space separated list of SIGNALs\n\nSIGNAL = ( 'hup' | 'int' | 'quit' | 'ill' | 'trap' | 'abrt' | 'bus' | 'fpe' | 'kill' |\n'usr1' | 'segv' | 'usr2' | 'pipe' | 'alrm' | 'term' | 'stkflt' | 'chld' | 'cont' | 'stop'\n| 'stp' | 'ttin' | 'ttou' | 'urg' | 'xcpu' | 'xfsz' | 'vtalrm' | 'prof' | 'winch' | 'io'\n| 'pwr' | 'sys' | 'emt' | 'exists' | 'rtmin+0' ... 'rtmin+32' )\n\nSIGNAL PEER = 'peer' '=' AARE\n\nDBUS RULE = ( DBUS MESSAGE RULE | DBUS SERVICE RULE | DBUS EAVESDROP RULE | DBUS COMBINED\nRULE )\n\nDBUS MESSAGE RULE = [ QUALIFIERS ] 'dbus' [ DBUS ACCESS EXPRESSION ] [ DBUS BUS ] [ DBUS\nPATH ] [ DBUS INTERFACE ] [ DBUS MEMBER ] [ DBUS PEER ]\n\nDBUS SERVICE RULE = [ QUALIFIERS ] 'dbus' [ DBUS ACCESS EXPRESSION ] [ DBUS BUS ] [ DBUS\nNAME ]\n\nDBUS EAVESDROP RULE = [ QUALIFIERS ] 'dbus' [ DBUS ACCESS EXPRESSION ] [ DBUS BUS ]\n\nDBUS COMBINED RULE = [ QUALIFIERS ] 'dbus' [ DBUS ACCESS EXPRESSION ] [ DBUS BUS ]\n\nDBUS ACCESS EXPRESSION = ( DBUS ACCESS | '(' DBUS ACCESS LIST ')' )\n\nDBUS BUS = 'bus' '=' '(' 'system' | 'session' | '\"' AARE '\"' | AARE ')'\n\nDBUS PATH = 'path' '=' '(' '\"' AARE '\"' | AARE ')'\n\nDBUS INTERFACE = 'interface' '=' '(' '\"' AARE '\"' | AARE ')'\n\nDBUS MEMBER = 'member' '=' '(' '\"' AARE '\"' | AARE ')'\n\nDBUS PEER = 'peer' '=' '(' [ DBUS NAME ] [ DBUS LABEL ] ')'\n\nDBUS NAME = 'name' '=' '(' '\"' AARE '\"' | AARE ')'\n\nDBUS LABEL = 'label' '=' '(' '\"' AARE '\"' | AARE ')'\n\nDBUS ACCESS LIST = Comma separated list of DBUS ACCESS\n\nDBUS ACCESS = ( 'send' | 'receive' | 'bind' | 'eavesdrop' | 'r' | 'read' | 'w' | 'write'\n| 'rw' )\nSome accesses are incompatible with some rules; see below.\n\nUNIX RULE = [ QUALIFIERS ] 'unix' [ UNIX ACCESS EXPR ] [ UNIX RULE CONDS ] [ UNIX LOCAL\nEXPR ] [ UNIX PEER EXPR ]\n\nUNIX ACCESS EXPR = ( UNIX ACCESS | UNIX ACCESS LIST )\n\nUNIX ACCESS = ( 'create' | 'bind' | 'listen' | 'accept' | 'connect' | 'shutdown' |\n'getattr' | 'setattr' | 'getopt' | 'setopt' | 'send' | 'receive' | 'r' | 'w' | 'rw' )\nSome access modes are incompatible with some rules or require additional parameters.\n\nUNIX ACCESS LIST = '(' UNIX ACCESS ( [','] UNIX ACCESS )* ')'\n\nUNIX RULE CONDS = ( TYPE COND | PROTO COND )\nEach cond can appear at most once.\n\nTYPE COND = 'type' '=' ( AARE | '(' ( '\"' AARE '\"' | AARE )+ ')' )\n\nPROTO COND = 'protocol' '=' ( AARE | '(' ( '\"' AARE '\"' | AARE )+ ')' )\n\nUNIX LOCAL EXPR = ( UNIX ADDRESS COND | UNIX LABEL COND | UNIX ATTR COND | UNIX OPT COND\n)*\nEach cond can appear at most once.\n\nUNIX PEER EXPR = 'peer' '=' ( UNIX ADDRESS COND | UNIX LABEL COND )+\nEach cond can appear at most once.\n\nUNIX ADDRESS COND 'addr' '=' ( AARE | '(' '\"' AARE '\"' | AARE ')' )\n\nUNIX LABEL COND 'label' '=' ( AARE | '(' '\"' AARE '\"' | AARE ')' )\n\nUNIX ATTR COND 'attr' '=' ( AARE | '(' '\"' AARE '\"' | AARE ')' )\n\nUNIX OPT COND 'opt' '=' ( AARE | '(' '\"' AARE '\"' | AARE ')' )\n\nRLIMIT RULE = 'set' 'rlimit' [RLIMIT '<=' RLIMIT VALUE ]\n\nRLIMIT = ( 'cpu' | 'fsize' | 'data' | 'stack' | 'core' | 'rss' | 'nofile' | 'ofile' |\n'as' | 'nproc' | 'memlock' | 'locks' | 'sigpending' | 'msgqueue' | 'nice' | 'rtprio' |\n'rttime' )\n\nRLIMIT VALUE = ( RLIMIT SIZE | RLIMIT NUMBER | RLIMIT TIME | RLIMIT NICE )\n\nRLIMIT SIZE = NUMBER ( 'K' | 'M' | 'G' )\nOnly applies to RLIMIT of 'fsize', 'data', 'stack', 'core', 'rss', 'as', 'memlock',\n'msgqueue'.\n\nRLIMIT NUMBER = number from 0 to max rlimit value.\nOnly applies to RLIMIT of 'ofile', 'nofile', 'locks', 'sigpending', 'nproc', 'rtprio'.\n\nRLIMIT TIME = NUMBER ( 'us' | 'microsecond' | 'microseconds' | 'ms' | 'millisecond' |\n'milliseconds' | 's' | 'sec' | 'second' | 'seconds' | 'min' | 'minute' | 'minutes' | 'h'\n| 'hour' | 'hours' | 'd' | 'day' | 'days' | 'week' | 'weeks' )\nOnly applies to RLIMIT of 'cpu' and 'rttime'. RLIMIT 'cpu' only allows units >=\n'seconds'.\n\nRLIMIT NICE = a number between -20 and 19.\nOnly applies to RLIMIT of 'nice'.\n\nFILE RULE = [ QUALIFIERS ] [ 'owner' ] ( 'file' | [ 'file' ] ( FILEGLOB ACCESS | ACCESS\nFILEGLOB ) [ '->' EXEC TARGET ] )\n\nFILEGLOB = ( QUOTED FILEGLOB | UNQUOTED FILEGLOB )\n\nQUOTED FILEGLOB = '\"' UNQUOTED FILEGLOB '\"'\n\nUNQUOTED FILEGLOB = (must start with '/' (after variable expansion), AARE have special\nmeanings; see below. May include VARIABLE. Rules with embedded spaces or tabs must be\nquoted. Rules must end with '/' to apply to directories.)\n\nAARE = ?*[]{}^\nSee section \"Globbing (AARE)\" below for meanings.\n\nACCESS = ( 'r' | 'w' | 'a' | 'l' | 'k' | 'm' | EXEC TRANSITION )+ (not all combinations\nare allowed; see below.)\n\nEXEC TRANSITION = ( 'ix' | 'ux' | 'Ux' | 'px' | 'Px' | 'cx' | 'Cx' | 'pix' | 'Pix' |\n'cix' | 'Cix' | 'pux' | 'PUx' | 'cux' | 'CUx' | 'x' )\nA bare 'x' is only allowed in rules with the deny qualifier, everything else only\nwithout the deny qualifier.\n\nEXEC TARGET = name\nRequires EXEC TRANSITION specified.\n\nLINK RULE = QUALIFIERS [ 'owner' ] 'link' [ 'subset' ] FILEGLOB '->' FILEGLOB\n\nALPHA = ('a', 'b', 'c', ... 'z', 'A', 'B', ... 'Z')\n\nALPHANUMERIC = ('0', '1', '2', ... '9', 'a', 'b', 'c', ... 'z', 'A', 'B', ... 'Z')\n\nCHANGEPROFILE RULE = 'changeprofile' [ [ EXEC MODE ] EXEC COND ] [ '->' PROFILE NAME ]\n\nEXECMODE = ( 'safe' | 'unsafe' )\n\nEXEC COND = FILEGLOB\n\nALL RULE = 'all'\n\nAll resources and programs need a full path. There may be any number of subprofiles (aka\nchild profiles) in a profile, limited only by kernel memory. Subprofile names are limited to\n974 characters. Child profiles can be used to confine an application in a special way, or\nwhen you want the child to be unconfined on the system, but confined when called from the\nparent. Hats are a special child profile that can be used with the aachangehat(2) API\ncall. Applications written or modified to use aachangehat(2) can take advantage of\nsubprofiles to run under different confinements, dependent on program logic. Several\naachangehat(2)-aware applications exist, including an Apache module, modapparmor(5); a PAM\nmodule, pamapparmor; and a Tomcat valve, tomcatapparmor. Applications written or modified\nto use changeprofile(2) transition permanently to the specified profile. libvirt is one such\napplication.\n", "subsections": [ { "name": "Profile Head", "content": "The profile head consists of a required name that is unique and optional attachment\nconditionals and control flags.\n\nName\n\nThe name of the profile is its identifier. It is what is displayed during introspection (eg.\nps -Z), and defines how the profile is referenced by policy rules for any policy interaction\nvia ipc or domain changes. It is recommended that the name be kept short and have meaning for\nthe application it is being applied eg. firefox for the firefox web browser or its functional\nrole eg. logadmin.\n\nIf the name is an applications full absolute path name eg. /usr/bin/firefox and an exec\nattachment conditional is not specified the name is also used as the profile's exec\nattachment conditional. This use however has been deprecated and is discouraged as it makes\nfor long names that can make profile rules difficult to understand, and may not be fully\ndisplayed by some introspection tools.\n\nAttachment Conditionals\n\nThe attachment conditionals are used during profile changes to determine whether a profile is\na match for the proposed profile transition. The attachment conditionals are optional, how\nand when they are applied is determined by the specific condition(s) used.\n\nWhen attachment conditionals are used, the attachment conditionals for all profiles in the\nnamespace will be evaluated. The profile with the set of attachments that result in the best\nmatch will become the new profile after a transition operation. Attachments that don't match\nwill result in the profile not being available for transition.\n\nIf no conditionals are specified the profile will only be used if a transition explicitly\nspecifies the profile name.\n\nExec Attachment Conditional\n\nThe exec attachment conditional governs how closely the profile matches an executable\nprogram. This conditional is only used during an exec operation when the matching exec rule\nspecifies either a px or cx (or their derivatives) transition type. The exec attachment\nconditional will also be used by tasks that are unconfined as they use a pix transition rule.\n\nIf there are no attachment matches then it is up to the exec rule to determine what happens\n(fail or a fallback option).\n\nNote: see profile Name for information around using the profile name as an attachment\nconditional.\n\nExec attachment conditionals can contain variable names and pattern matching. They use a\nlongest left match heuristic to deterime the winner in the case of multiple matches at run\ntime. The exact implementation of this resolution is kernel specific and has improved over\ntime, while retaining backwards compatibility. If the heuristic can not determine a winner\nbetween multiple matches the exec will be denied.\n\nExtended Attributes Attachment Conditional\n\nAppArmor profiles have the ability to target files based on their xattr(7) values in addition\nto their path. For example, the following profile matches files in /usr/bin with the\nattribute \"security.apparmor\" and value \"trusted\":\n\n/usr/bin/* xattrs(security.apparmor=\"trusted\") {\n# ...\n}\n\nSee apparmorxattrs(7) for further details.\n\nFlags\n\nThe profile flags allow modifying the behavior of the profile. If a profile flag is specified\nit takes priority over any conflicting flags that have been specified by rules in the profile\nbody.\n\nProfile Mode\n\nThe profile mode allow controlling the enforcement behavior of the profile rules.\n\nIf no mode is specified the profile defaults to enforce mode.\n\nenforce For a given action, if the profile rules do not grant permission the action will be\ndenied, with an EACCES or EPERM error code returned to userspace, and the violation will be\nlogged with a tag of the access being DENIED.\nkill This is a variant of enforce mode where in addition to returning EACCES or EPERM for a\nviolation, the task is also sent a signal to kill it.\ncomplain For a given action, if the profile rules do not grant permission the action will be\nallowed, but the violation will be logged with a tag of the access being ALLOWED.\ndefaultallow This mode changes the default behavior of apparmor from default deny to default\nallow. When defaultallow is specified the resulting profile will allow operations that the\nprofile does not have a rule for. This mode is similar to unconfined but allows for allow and\ndeny rules, specifying audit, and domain transitions. Profiles in this mode may be be\nreported as being in enforce mode or allow mode when introspected from the kernel.\nNote: defaultallow is similar and for many profiles will be equivalent to specifying\nan allow all, rule in the profile. The defaultallow flag does not provide all the\nsame option that the allow all, rule provides.\n\nunconfined This mode allows a task confined by the profile to behave as though it is\nunconfined. The unconfined behavior can be later changed to confinement by using profile\nreplacement. This mode should not be used under regular deployment but can be useful during\ndebugging and some system initialization scenarios.\nThis mode is similar to defaultallow and may be emulated by defaultallow in kernels\nthat no longer support a true unconfined mode. It does not generally allow for\nspecifying deny rules, or allow rules that override the default behavior, except in a\nfew custom kernels where unconfined restricts a few operations. It relies on special\ncustomized behavior of the unconfined profile in the kernel and as such should only\nbe used for debugging.\n\nNote: true unconfined is being phased out, with unconfined becoming a replaceable\nprofile. As such unconfined mode will be emulated by a special profile compiled with\nthe defaultallow flag in newer kernels.\n\nprompt This mode allows task mediation to send an up call to userspace to ask for a decision\nwhen there isn't a rule covering the permission request. If userspace does not respond then\nthe access will be denied.\n\nAudit Mode\n\nThe audit mode allows control of how AppArmor messages are are logged to the audit system.\n\naudit This flag causes all actions whether allowed or denied to be logged.\n\nMisc modes\n\nmediatedeleted This forces AppArmor to mediate deleted files as if they still exist in the\nfile system.\nattachdisconnected This forces AppArmor to attach disconnected objects to the task's\nnamespace and mediate them as though they are part of the namespace. WARNING this mode is\nunsafe and can result in aliasing and access to objects that should not be allowed. Its\nintent is a debug and policy development tool.\nattachdisconnected.path=ABS PATH Like attachdisconnected, but attach disconnected objects\nto the supplied path instead of the root of the namespace.\nchrootrelative This forces file names to be relative to a chroot and behave as if the chroot\nis a mount namespace.\ndebug This flag allows turning on kernel debug messages on a per profile basis. It works in\nconjunction with other kernel debug flags to control what messages will be output. Its effect\nis kernel dependent, and it should never appear in policy except when trying to debug kernel\nor policy problems.\ninterruptible Enables interrupts for prompt upcall to userspace.\nkill.signal=SIGNAL This changes the signal that will be sent by AppArmor when in kill mode or\na kill rule has been violated.\n" }, { "name": "Access Modes", "content": "File permission access modes consists of combinations of the following modes:\n\nr - read\n\nw - write -- conflicts with append\n\na - append -- conflicts with write\n\nux - unconfined execute\n\nUx - unconfined execute -- scrub the environment\n\npx - discrete profile execute\n\nPx - discrete profile execute -- scrub the environment\n\ncx - transition to subprofile on execute\n\nCx - transition to subprofile on execute -- scrub the environment\n\nix - inherit execute\n\npix - discrete profile execute with inherit fallback\n\nPix - discrete profile execute with inherit fallback -- scrub the environment\n\ncix - transition to subprofile on execute with inherit fallback\n\nCix - transition to subprofile on execute with inherit fallback -- scrub the environment\n\npux - discrete profile execute with fallback to unconfined\n\nPUx - discrete profile execute with fallback to unconfined -- scrub the environment\n\ncux - transition to subprofile on execute with fallback to unconfined\n\nCUx - transition to subprofile on execute with fallback to unconfined -- scrub the\nenvironment\n\ndeny x - disallow execute (in rules with the deny qualifier)\n\nm - allow PROTEXEC with mmap(2) calls\n\nl - link\n\nk - lock\n" }, { "name": "Access Modes Details", "content": "" }, { "name": "r - Read mode", "content": "Allows the program to have read access to the file or directory listing. Read access is\nrequired for shell scripts and other interpreted content.\n" }, { "name": "w - Write mode", "content": "Allows the program to have write access to the file. Files and directories must have this\npermission if they are to be unlinked (removed.) Write mode is not required on a\ndirectory to rename or create files within the directory.\n\nThis mode conflicts with append mode.\n" }, { "name": "a - Append mode", "content": "Allows the program to have a limited appending only write access to the file. Append\nmode will prevent an application from opening the file for write unless it passes the\nOAPPEND parameter flag on open.\n\nThe mode conflicts with Write mode.\n" }, { "name": "ux - Unconfined execute mode", "content": "Allows the program to execute the program without any AppArmor profile being applied to\nthe program.\n\nThis mode is useful when a confined program needs to be able to perform a privileged\noperation, such as rebooting the machine. By placing the privileged section in another\nexecutable and granting unconfined execution rights, it is possible to bypass the\nmandatory constraints imposed on all confined processes. For more information on what is\nconstrained, see the apparmor(7) man page.\n\nWARNING 'ux' should only be used in very special cases. It enables the designated child\nprocesses to be run without any AppArmor protection. 'ux' does not scrub the environment\nof variables such as LDPRELOAD; as a result, the calling domain may have an undue amount\nof influence over the callee. Use this mode only if the child absolutely must be run\nunconfined and LDPRELOAD must be used. Any profile using this mode provides negligible\nsecurity. Use at your own risk.\n\nIncompatible with other exec transition modes and the deny qualifier.\n" }, { "name": "Ux - unconfined execute -- scrub the environment", "content": "'Ux' allows the named program to run in 'ux' mode, but AppArmor will invoke the Linux\nKernel's unsafeexec routines to scrub the environment, similar to setuid programs. (See\nld.so(8) for some information on setuid/setgid environment scrubbing.)\n\nWARNING 'Ux' should only be used in very special cases. It enables the designated child\nprocesses to be run without any AppArmor protection. Use this mode only if the child\nabsolutely must be run unconfined. Use at your own risk.\n\nIncompatible with other exec transition modes and the deny qualifier.\n" }, { "name": "px - Discrete Profile execute mode", "content": "This mode requires that a discrete security profile is defined for a program executed and\nforces an AppArmor domain transition. If there is no profile defined then the access will\nbe denied.\n\nWARNING 'px' does not scrub the environment of variables such as LDPRELOAD; as a result,\nthe calling domain may have an undue amount of influence over the callee.\n\nIncompatible with other exec transition modes and the deny qualifier.\n" }, { "name": "Px - Discrete Profile execute mode -- scrub the environment", "content": "'Px' allows the named program to run in 'px' mode, but AppArmor will invoke the Linux\nKernel's unsafeexec routines to scrub the environment, similar to setuid programs. (See\nld.so(8) for some information on setuid/setgid environment scrubbing.)\n\nIncompatible with other exec transition modes and the deny qualifier.\n" }, { "name": "cx - Transition to Subprofile execute mode", "content": "This mode requires that a local security profile is defined and forces an AppArmor domain\ntransition to the named profile. If there is no profile defined then the access will be\ndenied.\n\nWARNING 'cx' does not scrub the environment of variables such as LDPRELOAD; as a result,\nthe calling domain may have an undue amount of influence over the callee.\n\nIncompatible with other exec transition modes and the deny qualifier.\n" }, { "name": "Cx - Transition to Subprofile execute mode -- scrub the environment", "content": "'Cx' allows the named program to run in 'cx' mode, but AppArmor will invoke the Linux\nKernel's unsafeexec routines to scrub the environment, similar to setuid programs. (See\nld.so(8) for some information on setuid/setgid environment scrubbing.)\n\nIncompatible with other exec transition modes and the deny qualifier.\n" }, { "name": "ix - Inherit execute mode", "content": "Prevent the normal AppArmor domain transition on execve(2) when the profiled program\nexecutes the named program. Instead, the executed resource will inherit the current\nprofile.\n\nThis mode is useful when a confined program needs to call another confined program\nwithout gaining the permissions of the target's profile, or losing the permissions of the\ncurrent profile. There is no version to scrub the environment because 'ix' executions\ndon't change privileges.\n\nIncompatible with other exec transition modes and the deny qualifier.\n" }, { "name": "Profile transition with inheritance fallback execute mode", "content": "These modes attempt to perform a domain transition as specified by the matching\npermission (shown below) and if that transition fails to find the matching profile the\ndomain transition proceeds using the 'ix' transition mode.\n\n'Pix' == 'Px' with fallback to 'ix'\n'pix' == 'px' with fallback to 'ix'\n'Cix' == 'Cx' with fallback to 'ix'\n'cix' == 'cx' with fallback to 'ix'\n\nIncompatible with other exec transition modes and the deny qualifier.\n" }, { "name": "Profile transition with unconfined fallback execute mode", "content": "These modes attempt to perform a domain transition as specified by the matching\npermission (shown below) and if that transition fails to find the matching profile the\ndomain transition proceeds using the 'ux' transition mode if 'pux', 'cux' or the 'Ux'\ntransition mode if 'PUx', 'CUx' is used.\n\n'PUx' == 'Px' with fallback to 'Ux'\n'pux' == 'px' with fallback to 'ux'\n'CUx' == 'Cx' with fallback to 'Ux'\n'cux' == 'cx' with fallback to 'ux'\n\nIncompatible with other exec transition modes and the deny qualifier.\n" }, { "name": "deny x - Deny execute", "content": "For rules including the deny modifier, only 'x' is allowed to deny execute.\n\nThe 'ix', 'Px', 'px', 'Cx', 'cx' and the fallback modes conflict with the deny modifier.\n" }, { "name": "Directed profile transitions", "content": "The directed ('px', 'Px', 'pix', 'Pix', 'pux', 'PUx') profile and subprofile ('cx', 'Cx',\n'cix', 'Cix', 'cux', 'CUx') transitions normally determine the profile to transition to\nfrom the executable name. It is however possible to specify the name of the profile that\nthe transition should use.\n\nThe name of the profile to transition to is specified using the '->' followed by the name\nof the profile to transition to. Eg.\n\n/bin/ px -> profile,\n\nIncompatible with other exec transition modes.\n" }, { "name": "m - Allow executable mapping", "content": "This mode allows a file to be mapped into memory using mmap(2)'s PROTEXEC flag. This\nflag marks the pages executable; it is used on some architectures to provide non-\nexecutable data pages, which can complicate exploit attempts. AppArmor uses this mode to\nlimit which files a well-behaved program (or all programs on architectures that enforce\nnon-executable memory access controls) may use as libraries, to limit the effect of\ninvalid -L flags given to ld(1) and LDPRELOAD, LDLIBRARYPATH, given to ld.so(8).\n" }, { "name": "l - Link mode", "content": "Allows the program to be able to create a link with this name. When a link is created,\nthe new link MUST have a subset of permissions as the original file (with the exception\nthat the destination does not have to have link access.) If there is an 'x' rule on the\nnew link, it must match the original file exactly.\n" }, { "name": "k - lock mode", "content": "Allows the program to be able lock a file with this name. This permission covers both\nadvisory and mandatory locking.\n" }, { "name": "leading OR trailing access permissions", "content": "File rules can be specified with the access permission either leading or trailing the\nfile glob. Eg.\n\nrw /, # leading permissions\n\n/ rw, # trailing permissions\n\nWhen leading permissions are used further rule options and context may be allowed, Eg.\n\nl /foo -> /bar, # lead 'l' link permission is equivalent to link rules\n" }, { "name": "Link rules", "content": "Link rules allow specifying permission to form a hard link as a link target pair. If the\nsubset condition is specified then the permissions to access the link file must be a subset\nof the profiles permissions to access the target file. If there is an 'x' rule on the new\nlink, it must match the original file exactly.\n\nEg.\n\n/file1 r,\n/file2 rwk,\n/link* rw,\nlink subset /link* -> /,\n\nThe link rule allows linking of /link to both /file1 or /file2 by name however because the\n/link file has 'rw' permissions it is not allowed to link to /file1 because that would grant\nan access path to /file1 with more permissions than the 'r' permissions the profile\nspecifies.\n\nA link of /link to /file2 would be allowed because the 'rw' permissions of /link are a subset\nof the 'rwk' permissions for /file1.\n\nThe link rule is equivalent to specifying the 'l' link permission as a leading permission\nwith no other file access permissions. When this is done the link rule options can be\nspecified.\n\nThe following link rule is equivalent to the 'l' permission file rule\n\nlink /foo -> bar,\nl /foo -> /bar,\n\nFile rules that specify the 'l' permission and don't specify the extend link permissions map\nto link rules as follows.\n\n/foo l,\nl /foo,\nlink subset /foo -> /,\n" }, { "name": "Comments", "content": "Comments start with # and may begin at any place within a line. The comment ends when the\nline ends. This is the same comment style as shell scripts.\n" }, { "name": "Capabilities", "content": "The only capabilities a confined process may use may be enumerated; for the complete list,\nplease refer to capabilities(7). Note that granting some capabilities renders AppArmor\nconfinement for that domain advisory; while open(2), read(2), write(2), etc., will still\nreturn error when access is not granted, some capabilities allow loading kernel modules,\narbitrary access to IPC, ability to bypass discretionary access controls, and other\noperations that are typically reserved for the root user.\n" }, { "name": "Network Rules", "content": "AppArmor supports simple coarse grained network mediation. The network rule restrict all\nsocket(2) based operations. The mediation done is a coarse-grained check on whether a socket\nof a given type and family can be created, read, or written. Network netlink(7) rules may\nonly specify type 'dgram' and 'raw'.\n\nAppArmor network rules are accumulated so that the granted network permissions are the union\nof all the listed network rule permissions.\n\nAppArmor network rules are broad and general and become more restrictive as further\ninformation is specified.\n\neg.\n\nnetwork, #allow access to all networking\nnetwork tcp, #allow access to tcp\nnetwork inet tcp, #allow access to tcp only for inet4 addresses\nnetwork inet6 tcp, #allow access to tcp only for inet6 addresses\nnetwork netlink raw, #allow access to AFNETLINK SOCKRAW\n\nNetwork permissions\n\nNetwork rule permissions are implied when a rule does not explicitly state an access list. By\ndefault if a rule does not have an access list all permissions that are compatible with the\nspecified set of local and peer conditionals are implied.\n\nThe create, bind, listen, shutdown, getattr, setattr, getopt, and setopt permissions are\nlocal socket permissions. They are only applied to the local socket and can't be specified in\nrules that have a peer conditional. The accept permission applies to the combination of a\nlocal and peer socket. The connect, send, and receive permissions are peer socket\npermissions.\n\nMediation of inet/inet6 family\n\nAppArmor supports fine grained mediation of the inet and inet6 families by using the ip and\nport conditionals. The ip conditional accepts both IPv4 and IPv6 using the regular\nrepresentation of four octets separated by '.' for IPv4 and eight groups of four hexadecimal\nnumbers separated by ':' for IPv6. Contiguous leading zeros can be replaced by '::' once. On\na connected socket, the sender and receiver don't need to be specified in the recvfrom and\nsendto system calls. In that case, and with unbounded sockets, the IP address is none, or\nunknown. Unknown or Unbound IP addresses are represented in policy by the 'none' keyword.\nWhen the ip conditional is omitted, then all IP addresses will be allowed: IPv4, IPv6 and\nnone. If INADDRANY or in6addrany is used, then the ip conditional can be omitted or they\ncan be represented by:\n\nnetwork ip=::, #allow in6addrany\nnetwork ip=0.0.0.0; #allow INADDRANY\n\nThe network rules support the specification of local and remote IP addresses and ports.\n\nnetwork ip=127.0.0.1 port=8080,\nnetwork peer=(ip=10.139.15.23 port=8081),\nnetwork ip=fd74:1820:b03a:b361::cf32 peer=(ip=fd74:1820:b03a:b361::a0f9),\nnetwork port=8080 peer=(port=8081),\nnetwork ip=127.0.0.1 port=8080 peer=(ip=10.139.15.23 port=8081),\n" }, { "name": "Mount Rules", "content": "AppArmor supports mount mediation and allows specifying filesystem types and mount flags. The\nsyntax of mount rules in AppArmor is based on the mount(8) command syntax. Mount rules must\ncontain one of the mount, remount or umount keywords, but all mount conditions are optional.\nUnspecified optional conditionals are assumed to match all entries (eg, not specifying fstype\nmeans all fstypes are matched). Due to the complexity of the mount command and how options\nmay be specified, AppArmor allows specifying conditionals three different ways:\n\n1. If a conditional is specified using '=', then the rule only grants permission for mounts\nmatching the exactly specified options. For example, an AppArmor policy with the\nfollowing rule:\n\nmount options=ro /dev/foo -E /mnt/,\n\nWould match:\n\n$ mount -o ro /dev/foo /mnt\n\nbut not either of these:\n\n$ mount -o ro,atime /dev/foo /mnt\n\n$ mount -o rw /dev/foo /mnt\n\n2. If a conditional is specified using 'in', then the rule grants permission for mounts\nmatching any combination of the specified options. For example, if an AppArmor policy has\nthe following rule:\n\nmount options in (ro,atime) /dev/foo -> /mnt/,\n\nall of these mount commands will match:\n\n$ mount -o ro /dev/foo /mnt\n\n$ mount -o ro,atime /dev/foo /mnt\n\n$ mount -o atime /dev/foo /mnt\n\nbut none of these will:\n\n$ mount -o ro,sync /dev/foo /mnt\n\n$ mount -o ro,atime,sync /dev/foo /mnt\n\n$ mount -o rw /dev/foo /mnt\n\n$ mount -o rw,noatime /dev/foo /mnt\n\n$ mount /dev/foo /mnt\n\n3. If multiple conditionals are specified in a single mount rule, then the rule grants\npermission for each set of options. This provides a shorthand when writing mount rules\nwhich might help to logically break up a conditional. For example, if an AppArmor policy\nhas the following rule:\n\nmount options=ro options=atime\n\nboth of these mount commands will match:\n\n$ mount -o ro /dev/foo /mnt\n\n$ mount -o atime /dev/foo /mnt\n\nbut this one will not:\n\n$ mount -o ro,atime /dev/foo /mnt\n\nNote that separate mount rules are distinct and the options do not accumulate. For example,\nthese AppArmor mount rules:\n\nmount options=ro,\n\nmount options=atime,\n\nare not equivalent to either of these mount rules:\n\nmount options=(ro,atime),\n\nmount options in (ro,atime),\n\nTo help clarify the flexibility and complexity of mount rules, here are some example rules\nwith accompanying matching commands:\n" }, { "name": "mount,", "content": "the 'mount' rule without any conditionals is the most generic and allows any mount.\nEquivalent to 'mount fstype= options= -> /'.\n" }, { "name": "mount /dev/foo,", "content": "allow mounting of /dev/foo anywhere with any options. Some matching mount commands:\n\n$ mount /dev/foo /mnt\n\n$ mount -t ext3 /dev/foo /mnt\n\n$ mount -t vfat /dev/foo /mnt\n\n$ mount -o ro,atime,noexec,nodiratime /dev/foo /srv/some/mountpoint\n" }, { "name": "mount options=ro /dev/foo,", "content": "allow mounting of /dev/foo anywhere, as read only. Some matching mount commands:\n\n$ mount -o ro /dev/foo /mnt\n\n$ mount -o ro /dev/foo /some/where/else\n" }, { "name": "mount options=(ro,atime) /dev/foo,", "content": "allow mount of /dev/foo anywhere, as read only and using inode access times. Some\nmatching mount commands:\n\n$ mount -o ro,atime /dev/foo /mnt\n\n$ mount -o ro,atime /dev/foo /some/where/else\n" }, { "name": "mount options in (ro,atime) /dev/foo,", "content": "allow mount of /dev/foo anywhere using some combination of 'ro' and 'atime' (see above).\nSome matching mount commands:\n\n$ mount -o ro /dev/foo /mnt\n\n$ mount -o atime /dev/foo /some/where/else\n\n$ mount -o ro,atime /dev/foo /some/other/place\n" }, { "name": "mount options=ro /dev/foo, mount options=atime /dev/foo,", "content": "allow mount of /dev/foo anywhere as read only, and allow mount of /dev/foo anywhere using\ninode access times. Note this is expressed as two different rules. Matches:\n\n$ mount -o ro /dev/foo /mnt/1\n\n$ mount -o atime /dev/foo /mnt/2\n\nmount -> /mnt/,\nallow mounting anything under a directory in /mnt/. Some matching mount commands:\n\n$ mount /dev/foo1 /mnt/1\n\n$ mount -o ro,atime,noexec,nodiratime /dev/foo2 /mnt/deep/path/foo2\n\nmount options=ro -> /mnt/,\nallow mounting anything under /mnt/, as read only. Some matching mount commands:\n\n$ mount -o ro /dev/foo1 /mnt/1\n\n$ mount -o ro /dev/foo2 /mnt/deep/path/foo2\n" }, { "name": "mount fstype=ext3 options=(rw,atime) /dev/sdb1 -> /mnt/stick/,", "content": "allow mounting an ext3 filesystem in /dev/sdb1 on /mnt/stick as read/write and using\ninode access times. Matches only:\n\n$ mount -o rw,atime /dev/sdb1 /mnt/stick\n" }, { "name": "mount options=(ro, atime) options in (nodev, user) /dev/foo -> /mnt/,", "content": "allow mounting /dev/foo on /mnt/ read only and using inode access times, in addition to\nallowing some combination of 'nodev' and 'user' to be added on top. Matches only:\n\n$ mount -o ro,atime /dev/foo /mnt\n\n$ mount -o ro,atime,nodev /dev/foo /mnt\n\n$ mount -o ro,atime,user /dev/foo /mnt\n\n$ mount -o ro,atime,nodev,user /dev/foo /mnt\n" }, { "name": "Message Queue rules", "content": "AppArmor supports mediation of POSIX and SYSV message queues.\n\nAppArmor Message Queue permissions are implied when a rule does not explicitly state an\naccess list. By default, all Message Queue permissions are implied.\n\nAppArmor Message Queue permissions become more restricted as further information is\nspecified. Policy can be specified by determining its access mode, type, label, and message\nqueue name.\n\nRegarding access modes, 'r' and 'read' are used to read messages from the queue. 'w' and\n'write' are used to write to the message queue. 'create' is used to create the message queue,\nand 'open' is used to get the message queue identifier when the queue is already created.\n'delete' is used to remove the message queue. The access modes to get and set attributes of\nthe message queue are 'setattr' and 'getattr'.\n\nThe type of the policy can be either 'posix' or 'sysv'. This information is relevant when the\nmessage queue name is not specified, and when specified can be inferred by the queue name,\nsince message queues' name for posix must start with '/', and message queues' key for SYSV\nmust be a positive integer.\n\nThe policy label is the label assigned to the message queue when it is created.\n\nThe message queue name can be either a string starting with '/' if the type is POSIX, or a\npositive integer if the type is SYSV. If the type is not specified, then it will be inferred\nby the queue name.\n\nExample AppArmor Message Queue rules:\n\n# Allow all Message Queue access\nmqueue,\n\n# Explicitly allow all Message Queue access,\nmqueue (create, open, delete, read, write, getattr, setattr),\n\n# Explicitly deny use of Message Queue\ndeny mqueue,\n\n# Allow all access for POSIX queue of name /bar\nmqueue type=posix /bar,\n\n# Allow create permission for a SYSV queue of label foo\nmqueue create label=foo 123,\n" }, { "name": "User Namespace Rules", "content": "User namespaces are part of many sandboxing and containerization solutions. They provide a\nway for a non-system root process to be root within the container. Unfortunately this opens\nup attack surface in the kernel and has been part of several exploit chains. As such AppArmor\ncan be used to restrict the creation of user namespaces to select processes.\n\nUser namespace permission are implied when a rule does not explicitly state an access list.\nThe rule becomes more restrictive as further information is specified.\n\nNote: user namespace creation may be restricted so that it is not available to unprivieged\nunconfined processes. If this is the case any process trying to create user namespaces will\nrequire a profile that allows the necessary permissions.\n" }, { "name": "create", "content": "Allow creation of user namespaces.\n\nExample userns rules:\n\n# Allow all userns perms\nuserns,\n\n# Allow creation of a userns\nuserns create,\n" }, { "name": "IO_URing Rules", "content": "AppArmor supports mediation of the new Linux high speed IO interface. There is limited\nmediation at this time to just a few permissions at the moment.\n\nIO Uring permission are implied when a rule does not explicitly state an access list. The\nrule becomes more restrictive as further information is specified.\n\nNote: iouring access may be restricted so that it is not available to unprivileged\nunconfined processes. If this is the case any process trying to use iouring will require a\nprofile that allows the necessary iouring permissions.\n" }, { "name": "sqpoll", "content": "All the task confined by the profile to spawn a iouring polling thread.\n" }, { "name": "override_creds", "content": "Grants the task confined by the profile to override (change) its credentials to the\nspecified label, when executing an iouring operation.\n\nExample IOURING rules:\n\n# Allow iouring operations\nioring,\n\n# Allow creation of a polling thread\niouring sqpoll,\n\n# Allow task to override credentials during iouring operation\niouring overridecreds label=newcreds,\n" }, { "name": "Pivot Root Rules", "content": "AppArmor mediates changing of the root filesystem through the pivotroot(2) system call. The\nsyntax of 'pivotroot' rules in AppArmor is based on the pivotroot(2) system call parameters\nwith the notable exception that the ordering is reversed. The path corresponding to the\nputold parameter of pivotroot(2) is optionally specified in the 'pivotroot' rule using the\n'oldroot=' prefix.\n\nAppArmor 'pivotroot' rules can specify a profile transition to occur during the\npivotroot(2) system call. Note that AppArmor will only transition the process calling\npivotroot(2) to the new profile.\n\nThe paths specified in 'pivotroot' rules must end with '/' since they are directories.\n\nHere are some example 'pivotroot' rules:\n\n# Allow any pivot\npivotroot,\n\n# Allow pivoting to any new root directory and putting the old root\n# directory at /mnt/root/old/\npivotroot oldroot=/mnt/root/old/,\n\n# Allow pivoting the root directory to /mnt/root/\npivotroot /mnt/root/,\n\n# Allow pivoting to /mnt/root/ and putting the old root directory at\n# /mnt/root/old/\npivotroot oldroot=/mnt/root/old/ /mnt/root/,\n\n# Allow pivoting to /mnt/root/, putting the old root directory at\n# /mnt/root/old/ and transition to the /mnt/root/sbin/init profile\npivotroot oldroot=/mnt/root/old/ /mnt/root/ -> /mnt/root/sbin/init,\n" }, { "name": "PTrace rules", "content": "AppArmor supports mediation of ptrace(2). AppArmor PTrace rules are accumulated so that the\ngranted PTrace permissions are the union of all the listed PTrace rule permissions.\n\nAppArmor PTrace permissions are implied when a rule does not explicitly state an access list.\nBy default, all PTrace permissions are implied.\n\nThe trace and tracedby permissions govern ptrace(2) while read and readby govern certain\nproc(5) filesystem accesses, kcmp(2), futexes (getrobustlist(2)) and perf trace events.\n\nFor a ptrace operation to be allowed the profile of the tracing process and the profile of\nthe target task must both have the correct permissions. For example, the profile of the\nprocess attaching to another task must have the trace permission for the target task's\nprofile, and the task being traced must have the tracedby permission for the tracing process'\nprofile.\n\nExample AppArmor PTrace rules:\n\n# Allow all PTrace access\nptrace,\n\n# Explicitly allow all PTrace access,\nptrace (read, readby, trace, tracedby),\n\n# Explicitly deny use of ptrace(2)\ndeny ptrace (trace),\n\n# Allow unconfined processes (eg, a debugger) to ptrace us\nptrace (readby, tracedby) peer=unconfined,\n\n# Allow ptrace of a process running under the /usr/bin/foo profile\nptrace (trace) peer=/usr/bin/foo,\n" }, { "name": "Signal rules", "content": "AppArmor supports mediation of signal(7). AppArmor signal rules are accumulated so that the\ngranted signal permissions are the union of all the listed signal rule permissions.\n\nAppArmor signal permissions are implied when a rule does not explicitly state an access list.\nBy default, all signal permissions are implied.\n\nFor the sending of a signal to be allowed, the profile of the sending process and the profile\nof the target task must both have the correct permissions. For example, the profile of a\nprocess sending a signal to another task must have the send permission for the target task's\nprofile, and the task receiving the signal must have a receive permission for the sending\nprocess' profile.\n\nExample AppArmor signal rules:\n\n# Allow all signal access\nsignal,\n\n# Explicitly deny sending the HUP and INT signals\ndeny signal (send) set=(hup, int),\n\n# Allow unconfined processes to send us signals\nsignal (receive) peer=unconfined,\n\n# Allow sending of signals to a process running under the /usr/bin/foo\n# profile\nsignal (send) peer=/usr/bin/foo,\n\n# Allow checking for PID existence\nsignal (receive, send) set=(\"exists\"),\n\n# Allow us to signal ourselves using the built-in @{profilename} variable\nsignal peer=@{profilename},\n\n# Allow two real-time signals\nsignal set=(rtmin+0 rtmin+32),\n" }, { "name": "DBus rules", "content": "AppArmor supports DBus mediation. The mediation is performed in conjunction with the DBus\ndaemon. The DBus daemon verifies that communications over the bus are permitted by AppArmor\npolicy.\n\nAppArmor DBus rules are accumulated so that the granted DBus permissions are the union of all\nthe listed DBus rule permissions.\n\nAppArmor DBus rules are broad and general and become more restrictive as further information\nis specified. Policy may be specified down to the interface member level (method or signal\nname), however the contents of messages are not examined.\n\nSome AppArmor DBus permissions are not compatible with all AppArmor DBus rules. The 'bind'\npermission cannot be used in message rules. The 'send' and 'receive' permissions cannot be\nused in service rules. The 'eavesdrop' permission cannot be used in rules containing any\nconditionals outside of the 'bus' conditional.\n\n'r' and 'read' are synonyms for 'receive'. 'w' and 'write' are synonyms for 'send'. 'rw' is a\nsynonym for both 'send' and 'receive'.\n\nAppArmor DBus permissions are implied when a rule does not explicitly state an access list.\nBy default, all DBus permissions are implied. Only message permissions are implied for\nmessage rules and only service permissions are implied for service rules.\n\nExample AppArmor DBus rules:\n\n# Allow all DBus access\ndbus,\n\n# Explicitly allow all DBus access,\ndbus (send, receive, bind),\n\n# Deny send/receive/bind access to the session bus\ndeny dbus bus=session,\n\n# Allow bind access for a particular name on any bus\ndbus bind name=com.example.ExampleName,\n\n# Allow receive access for a particular path and interface\ndbus receive path=/com/example/path interface=com.example.Interface,\n\n# Deny send/receive access to the system bus for a particular interface\ndeny dbus bus=system interface=com.example.ExampleInterface,\n\n# Allow send access for a particular path, interface, member, and pair of\n# peer names:\ndbus send\nbus=session\npath=/com/example/path\ninterface=com.example.Interface\nmember=ExampleMethod\npeer=(name=(com.example.ExampleName1|com.example.ExampleName2)),\n\n# Allow receive access for all unconfined peers\ndbus receive peer=(label=unconfined),\n\n# Allow eavesdropping on the system bus\ndbus eavesdrop bus=system,\n\n# Allow and audit all eavesdropping\naudit dbus eavesdrop,\n" }, { "name": "Unix socket rules", "content": "AppArmor supports fine grained mediation of unix domain abstract and anonymous sockets. Unix\ndomain sockets with file system paths are mediated via file access rules.\n\nAbstract unix domain sockets is a nonportable Linux extension of unix domain sockets, see\nunix(7) for more information.\n\nUnix socket address paths\n\nThe sunpath component (aka the socket address) of a unix domain socket is specified by the\n\naddr=\n\nconditional. If an address conditional is not specified as part of a rule then the rule\nmatches both abstract and anonymous sockets.\n\nIn apparmor the address of an abstract unix domain socket begins with the @ character,\nsimilar to how they are reported (as paths) by netstat -x. The address then follows and may\ncontain pattern matching and any characters including the null character. In apparmor null\ncharacters must be specified by using an escape sequence \\000 or \\x00. The pattern matching\nis the same as is used by file path matching so * will not match / even though it has no\nspecial meaning with in an abstract socket name. Eg.\n\nunix addr=@*,\n\nAutobound unix domain sockets have a unix sunpath assigned to them by the kernel, as such\nspecifying a policy based address is not possible. The autobinding of sockets can be\ncontrolled by specifying the special auto keyword. Eg.\n\nunix addr=auto,\n\nTo indicate that the rule only applies to auto binding of unix domain sockets. It is\nimportant to note this only applies to the bind permission as once the socket is bound to an\naddress it is indistinguishable from a socket that have an addr bound with a specified name.\nWhen the auto keyword is used with other permissions or as part of a peer addr it will be\nreplaced with a pattern that can match an autobound socket. Eg. For some kernels\n\nunix rw addr=auto,\n\nis transformed to\n\nunix rw addr=@[a-f0-9][a-f0-9][a-f0-9][a-f0-9][a-f0-9],\n\nIt is important to note, this pattern may match abstract sockets that were not autobound but\nhave an addr that fits what is generated by the kernel when autobinding a socket.\n\nAnonymous unix domain sockets have no sunpath associated with the socket address, however it\ncan be specified with the special none keyword to indicate the rule only applies to anonymous\nunix domain sockets. Eg.\n\nunix addr=none,\n\nIf the address component of a rule is not specified then the rule applies to autobind,\nabstract and anonymous sockets.\n\nUnix socket permissions\n\nUnix domain socket rules are accumulated so that the granted unix socket permissions are the\nunion of all the listed unix rule permissions.\n\nUnix domain socket rules are broad and general and become more restrictive as further\ninformation is specified. Policy may be specified down to the socket address (aka sunpath)\nand label level. The content of the communication is not examined.\n\nUnix socket rule permissions are implied when a rule does not explicitly state an access\nlist. By default if a rule does not have an access list all permissions that are compatible\nwith the specified set of local and peer conditionals are implied.\n\nThe create, bind, listen, shutdown, getattr, setattr, getopt, and setopt permissions are\nlocal socket permissions. They are only applied to the local socket and can't be specified in\nrules that have a peer component. The accept permission applies to the combination of a local\nand peer socket. The connect, send, and receive permissions are peer socket permissions.\n\nOnly the peer socket permissions will be applied to rules that don't specify permissions and\ncontain a peer component.\n\nExample Unix domain socket rules:\n\n# Allow all permissions to unix sockets\nunix,\n\n# Explicitly allow all unix permissions\nunix (create, listen, accept, connect, send, receive, getattr, setattr, setopt, getopt),\n\n# Explicitly deny unix socket access\ndeny unix,\n\n# Allow create and use of abstract and anonymous sockets for profilename\nunix peer=(label=@{profilename}),\n\n# Allow receiving via unix sockets from unconfined\nunix (receive) peer=(label=unconfined),\n\n# Allow getattr and shutdown on anonymous sockets\nunix (getattr, shutdown) addr=none,\n\n# Allow SOCKSTREAM connect, receive and send on an abstract socket @bar\n# with peer running under profile '/foo'\nunix (connect, receive, send) type=stream peer=(label=/foo,addr=\"@bar\"),\n\n# Allow accepting connections from and receiving from peer running under\n# profile '/bar' on abstract socket '@foo'\nunix (accept, receive) addr=@foo peer=(label=/bar),\n\nAbstract unix domain sockets autobind\n\nAbstract unix domain sockets can autobind to an address. The autobind address is a unique 5\ndigit string of decimal numbers, eg. @00001. There is nothing that prevents a task from\nmanually binding to addresses with a similar pattern so it is impossible to reliably identify\nautobind addresses from a regular address.\n\nInteraction of network rules and fine grained unix domain socket rules\n\nThe coarse grained networking rules can be used to control unix domain sockets as well. When\nfine grained unix domain socket mediation is available the coarse grained network rule is\nmapped into the equivalent unix socket rule.\n\nE.G.\n\nnetwork unix, => unix,\n\nnetwork unix stream, => unix stream,\n\nFine grained mediation rules however can not be losslessly converted back to the coarse\ngrained network rule; e.g.\n\nunix bind addr=@example,\n\nHas no exact match under coarse grained network rules, the closest match is the much wider\npermission rule of\n\nnetwork unix,\n" }, { "name": "change_profile rules", "content": "AppArmor supports self directed profile transitions via the changeprofile api.\nChangeprofile rules control which permissions for which profiles a confined task can\ntransition to. The profile name can contain apparmor pattern matching to specify different\nprofiles.\n\nchangeprofile -> ,\n\nThe changeprofile api allows the transition to be delayed until when a task executes another\napplication. If an exec rule transition is specified for the application and the\nchangeprofile api is used to make a transition at exec time, the transition specified by the\nchangeprofile api takes precedence.\n\nThe Changeprofile permission can restrict which profiles can be transitioned to based off of\nthe executable name by specifying the exec condition.\n\nchangeprofile /bin/bash -> newprofile,\n\nThe restricting of the transition profile to a given executable at exec time is only useful\nwhen then current task is allowed to make dynamic decisions about what confinement should be,\nbut the decision set needs to be controlled. A list of profiles or multiple rules can be used\nto specify the profiles in the set. Eg.\n\nchangeprofile /bin/bash -> {newprofile1,newprofile2,newprofile3},\n\nAn exec rule can be used to specify a transition for the executable, if the transition should\nbe allowed even if the changeprofile api has not been used to select a transition for those\navailable in the changeprofile rule set. Eg.\n\n/bin/bash Px -> newprofile1,\nchangeprofile /bin/bash -> {newprofile1,newprofile2,newprofile3},\n\nThe exec mode dictates whether or not the Linux Kernel's unsafeexec routines should be used\nto scrub the environment, similar to setuid programs. (See ld.so(8) for some information on\nsetuid/setgid environment scrubbing.) The safe mode sets up environment scrubbing to occur\nwhen the new application is executed and unsafe mode disables AppArmor's requirement for\nenvironment scrubbing (the kernel and/or libc may still require environment scrubbing). An\nexec mode can only be specified when an exec condition is present.\n\nchangeprofile safe /bin/bash -> newprofile,\n\nNot all kernels support safe mode and the parser will downgrade rules to unsafe mode in that\nsituation. If no exec mode is specified, the default is safe mode in kernels that support it.\n" }, { "name": "all rule", "content": "The all rule is used to add a generic rule for all supported rule types. This is useful when\npolicy wants to define a black list instead of white list, but can also be useful to add an\naccess qualifier to all rules.\n\nEg. Black list\n\nallow all,\n# begin blacklist\ndeny file,\ndeny unix,\n\nEg. Adding audit qualifier\n\naudit access all,\n" }, { "name": "rlimit rules", "content": "AppArmor can set and control the resource limits associated with a profile as described in\nthe setrlimit(2) man page.\n\nThe AppArmor rlimit controls allow setting of limits and restricting changes of them and\nthese actions can be audited. Enforcement of the set limits is handled by the standard kernel\nenforcement mechanism for rlimits and will not result in an audited apparmor message if the\nlimit is enforced.\n\nIf a profile does not have an rlimit rule associated with a given rlimit then the rlimit is\nleft alone and regular access, including changing the limit, is allowed. However if the\nprofile sets an rlimit then the current limit is checked and if greater than the limit\nspecified in the rule it will be changed to the specified limit.\n\nAppArmor rlimit rules control the hard limit of an application and ensure that if the hard\nlimit is lowered that the soft limit does not exceed the hard limit value.\n\nEg.\n\nset rlimit data <= 100M,\nset rlimit nproc <= 10,\nset rlimit nice <= 5,\n" }, { "name": "Variables", "content": "AppArmor's policy language allows embedding variables into file rules to enable easier\nconfiguration for some common (and pervasive) setups. Variables may have multiple values\nassigned, but any variable assignments must be made before the start of the profile.\n\nThe parser will automatically expand variables to include all values that they have been\nassigned; it is an error to reference a variable without setting at least one value. You can\nuse empty quotes (\"\") to explicitly add an empty value.\n\nAt the time of this writing, the following variables are defined in the provided AppArmor\npolicy:\n\n@{HOME}\n@{HOMEDIRS}\n@{multiarch}\n@{pid}\n@{pids}\n@{PROC}\n@{securityfs}\n@{apparmorfs}\n@{sys}\n@{tid}\n@{run}\n@{XDGDESKTOPDIR}\n@{XDGDOWNLOADDIR}\n@{XDGTEMPLATESDIR}\n@{XDGPUBLICSHAREDIR}\n@{XDGDOCUMENTSDIR}\n@{XDGMUSICDIR}\n@{XDGPICTURESDIR}\n@{XDGVIDEOSDIR}\n\nThese are defined in files in /etc/apparmor.d/tunables and are used in many of the\nabstractions described later.\n\nYou may also add files in /etc/apparmor.d/tunables/home.d for site-specific customization of\n@{HOMEDIRS}, /etc/apparmor.d/tunables/multiarch.d for @{multiarch} and\n/etc/apparmor.d/tunables/xdg-user-dirs.d for @{XDG*}.\n\nThe special @{profilename} variable is set to the profile name and may be used in all\npolicy.\n" }, { "name": "Alias rules", "content": "AppArmor also provides alias rules for remapping paths for site-specific layouts. They are an\nalternative form of path rewriting to using variables, and are done after variable\nresolution. Alias rules must occur within the preamble of the profile. System-wide aliases\nare found in /etc/apparmor.d/tunables/alias, which is included by\n/etc/apparmor.d/tunables/global. /etc/apparmor.d/tunables/global is typically included at the\nbeginning of an AppArmor profile.\n" }, { "name": "Globbing (AARE)", "content": "File resources and other parameters accepting an AARE may be specified with a globbing syntax\nsimilar to that used by popular shells, such as csh(1), bash(1), zsh(1).\n\n* can substitute for any number of characters, excepting '/'\n\ncan substitute for any number of characters, including '/'\n\n? can substitute for any single character excepting '/'\n" }, { "name": "[abc]", "content": "will substitute for the single character a, b, or c\n" }, { "name": "[a-c]", "content": "will substitute for the single character a, b, or c\n" }, { "name": "[^a-c]", "content": "will substitute for any single character not matching a, b or c\n" }, { "name": "{ab,cd}", "content": "will expand to one rule to match ab, one rule to match cd\n\nCan also include variables.\n" }, { "name": "@{variable}", "content": "will expand to all values assigned to the given variable.\n\nWhen AppArmor looks up a directory the pathname being looked up will end with a slash (e.g.,\n/var/tmp/); otherwise it will not end with a slash. Only rules that match a trailing slash\nwill match directories. Some examples, none matching the /tmp/ directory itself, are:\n\n/tmp/*\nFiles directly in /tmp.\n\n/tmp/*/\nDirectories directly in /tmp.\n\n/tmp/\nFiles and directories anywhere underneath /tmp.\n\n/tmp//\nDirectories anywhere underneath /tmp.\n" }, { "name": "Rule Qualifiers", "content": "There are several rule qualifiers that can be applied to permission rules. Rule qualifiers\ncan modify the rule and/or permissions within the rule.\n" }, { "name": "allow", "content": "Specifies that permissions requests that match the rule are allowed. This is the default\nvalue for rules and does not need to be specified. Conflicts with the deny qualifier.\n" }, { "name": "audit", "content": "Specifies that permissions requests that match the rule should be recorded to the audit\nlog.\n" }, { "name": "deny", "content": "Specifies that permissions requests that match the rule should be denied without logging.\nCan be combined with 'audit' to enable logging. Conflicts with the allow qualifier.\n" }, { "name": "owner", "content": "Specifies that the task must have the same euid/fsuid as the object being referenced by\nthe permission check.\n\nQualifier Blocks\n\nRule Qualifiers can be applied to multiple rules at a time by grouping the rules into a rule\nblock.\n\naudit {\n/foo r,\nnetwork,\n}\n" }, { "name": "#include mechanism", "content": "AppArmor provides an easy abstraction mechanism to group common access requirements; this\nabstraction is an extremely flexible way to grant site-specific rights and makes writing new\nAppArmor profiles very simple by assembling the needed building blocks for any given program.\n\nThe use of '#include' is modelled directly after cpp(1); its use will replace the '#include'\nstatement with the specified file's contents. The leading '#' is optional, and the\n'#include' keyword can be followed by an option conditional 'if exists' that specifies\nprofile compilation should continue if the specified file or directory is not found.\n\n#include \"/absolute/path\" specifies that /absolute/path should be used. #include\n\"relative/path\" specifies that relative/path should be used, where the path is relative to\nthe current working directory. #include is the most common usage; it will load\nmagic/path relative to a directory specified to apparmorparser(8). /etc/apparmor.d/ is the\nAppArmor default.\n\nThe supplied AppArmor profiles follow several conventions; the abstractions stored in\n/etc/apparmor.d/abstractions/ are some large clusters that are used in most profiles. What\nfollows are short descriptions of how some of the abstractions are used.\n\nabstractions/audio\nIncludes accesses to device files used for audio applications.\n\nabstractions/authentication\nIncludes access to files and services typically necessary for services that perform user\nauthentication.\n\nabstractions/base\nIncludes files that should be readable and writable in all profiles.\n\nabstractions/bash\nIncludes many files used by bash; useful for interactive shells and programs that call\nsystem(3).\n\nabstractions/consoles\nIncludes read and write access to the device files controlling the virtual console,\nsshd(8), xterm(1), etc. This abstraction is needed for many programs that interact with\nusers.\n\nabstractions/fonts\nIncludes access to fonts and the font libraries.\n\nabstractions/gnome\nIncludes read and write access to GNOME configuration files, as well as read access to\nGNOME libraries.\n\nabstractions/kde\nIncludes read and write access to KDE configuration files, as well as read access to KDE\nlibraries.\n\nabstractions/kerberosclient\nIncludes file access rules needed for common kerberos clients.\n\nabstractions/nameservice\nIncludes file rules to allow DNS, LDAP, NIS, SMB, user and group password databases,\nservices, and protocols lookups.\n\nabstractions/perl\nIncludes read access to perl modules.\n\nabstractions/user-download\nabstractions/user-mail\nabstractions/user-manpages\nabstractions/user-tmp\nabstractions/user-write\nSome profiles for typical \"user\" programs will use these include files to describe rights\nthat users have in the system.\n\nabstractions/wutmp\nIncludes write access to files used to maintain wtmp(5) and utmp(5) databases, used with\nthe w(1) and associated commands.\n\nabstractions/X\nIncludes read access to libraries, configuration files, X authentication files, and the X\nsocket.\n\nSome of the abstractions rely on variables that are set in files in the\n/etc/apparmor.d/tunables/ directory. These variables are currently @{HOME} and @{HOMEDIRS}.\nVariables cannot be set in profile scope; they can only be set before the profile. Therefore,\nany profiles that use abstractions should either #include or otherwise\nensure that @{HOME} and @{HOMEDIRS} are set before starting the profile definition. The\naa-autodep(8) and aa-genprof(8) utilities will automatically emit #include \nin generated profiles.\n" }, { "name": "Feature ABI", "content": "The feature abi tells AppArmor which feature set the policy was developed under. This is\nimportant to ensure that kernels with a different feature set don't enforce features that the\npolicy doesn't support, which can result in unexpected application failures.\n\nWhen policy is compiled both the kernel feature abi and policy feature abi are consulted to\nbuild a policy that will work for the system's kernel.\n\nIf the kernel supports a feature not supported by the policy then policy will be built so\nthat the kernel does NOT enforce that feature.\n\nIf the policy supports a feature not supported by the kernel the compile may downgrade the\nrule with the feature to something the kernel supports, drop the rule completely, or fail the\ncompile.\n\nIf the policy abi is specified as kernel then the running kernel's abi will be used. This\nshould never be used in shipped policy as it can cause system breakage when a new kernel is\ninstalled.\n\nABI compatibility with AppArmor 2.x\n\nAppArmor 3 remains compatible with AppArmor 2.x by detecting when a profile does not have a\nfeature ABI specified. In this case the policy compile will either apply the pinned feature\nABI as specified by the config file or the command line, or if neither of those are applied\nby using a default feature ABI.\n\nIt is important to note that the default feature ABI does not support new features added in\nAppArmor 3 or later.\n" } ] }, "EXAMPLE": { "content": "An example AppArmor profile:\n\n# which feature abi the policy was developed with\nabi ,\n\n# a variable definition in the preamble\n@{HOME} = /home/*/ /root/\n\n# a comment about foo.\n/usr/bin/foo {\n/bin/mount ux,\n/dev/{,u}random r,\n/etc/ld.so.cache r,\n/etc/foo.conf r,\n/etc/foo/* r,\n/lib/ld-*.so* rmix,\n/lib/lib*.so* r,\n/proc/[0-9] r,\n/usr/lib/ r,\n/tmp/foo.pid wr,\n/tmp/foo.* lrw,\n/@{HOME}/.foofile rw,\n/usr/bin/baz Cx -> baz,\n\n# a comment about foo's hat (subprofile), bar.\n^bar {\n/lib/ld-*.so* rmix,\n/usr/bin/bar rmix,\n/var/spool/* rwl,\n}\n\n# a comment about foo's subprofile, baz.\nprofile baz {\n#include \nowner /proc/[0-9]*/stat r,\n/bin/bash ixr,\n/var/lib/baz/ r,\nowner /var/lib/baz/* rw,\n}\n}\n", "subsections": [] }, "FILES": { "content": "/etc/apparmor.d/\n", "subsections": [] }, "KNOWN BUGS": { "content": "• Mount options support the use of pattern matching but mount flags are not correctly\nintersected against specified patterns. Eg, 'mount options=,' should be equivalent to\n'mount,', but it is not. (LP: #965690)\n\n• The fstype may not be matched against when certain mount command flags are used.\nSpecifically fstype matching currently only works when creating a new mount and not\nremount, bind, etc.\n\n• Mount rules with multiple 'options' conditionals are not applied as documented but\ninstead merged such that 'options in (ro,nodev) options in (atime)' is equivalent to\n'options in (ro,nodev,atime)'.\n\n• When specifying mount options with the 'in' conditional, both the positive and negative\nvalues match when specifying one or the other. Eg, 'rw' matches when 'ro' is specified\nand 'dev' matches when 'nodev' is specified such that 'options in (ro,nodev)' is\nequivalent to 'options in (rw,dev)'.\n", "subsections": [] }, "SEE ALSO": { "content": "apparmor(7), apparmorparser(8), apparmorxattrs(7), aa-complain(1), aa-enforce(1),\naachangehat(2), modapparmor(5), and .\n\nAppArmor 4.0.1 2026-04-13 APPARMOR.D(5)", "subsections": [] } }, "summary": "apparmor.d - syntax of security profiles for AppArmor.", "flags": [], "examples": [ "An example AppArmor profile:", "# which feature abi the policy was developed with", "abi ,", "# a variable definition in the preamble", "@{HOME} = /home/*/ /root/", "# 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* rmix,", "/lib/lib*.so* r,", "/proc/[0-9] r,", "/usr/lib/ r,", "/tmp/foo.pid wr,", "/tmp/foo.* lrw,", "/@{HOME}/.foofile rw,", "/usr/bin/baz Cx -> baz,", "# a comment about foo's hat (subprofile), bar.", "^bar {", "/lib/ld-*.so* rmix,", "/usr/bin/bar rmix,", "/var/spool/* rwl,", "# a comment about foo's subprofile, baz.", "profile baz {", "#include ", "owner /proc/[0-9]*/stat r,", "/bin/bash ixr,", "/var/lib/baz/ r,", "owner /var/lib/baz/* rw," ], "see_also": [ { "name": "apparmor", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/apparmor/7/json" }, { "name": "apparmorparser", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/apparmorparser/8/json" }, { "name": "apparmorxattrs", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/apparmorxattrs/7/json" }, { "name": "aa-complain", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/aa-complain/1/json" }, { "name": "aa-enforce", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/aa-enforce/1/json" }, { "name": "aachangehat", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/aachangehat/2/json" }, { "name": "modapparmor", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/modapparmor/5/json" } ] }