默认 AppArmor profile 通过其名称附加到程序，因此 profile 名称必须与要限制的应用程序的路径匹配。

/usr/bin/foo {
...
}

每当执行未受限制的进程 /usr/bin/foo 时，都会自动使用此 profile。

未附加 profile 不驻留在文件系统命名空间中，因此不会自动附加到应用程序。未附加 profile 的名称以前缀 profile 开头。您可以自由选择 profile 名称，但有一些限制：名称不能以 ： 或 . 开头。如果它包含空格，则必须用引号括起来。如果名称以 / 开头，则该 profile 被视为标准 profile，因此以下两个 profile 相同

profile /usr/bin/foo {
...
}
/usr/bin/foo {
...
}

未附加 profile 绝不会自动使用，也不能通过 Px 规则进行转换。需要通过使用命名 profile 转换（请参阅 第 30.12.7 节，“命名 profile 转换”）或使用 change_profile 规则（请参阅 第 30.2.5 节，“更改规则”）将其附加到程序。

未附加 profile 对于通常不应由系统范围 profile 限制的系统实用程序（例如 /bin/bash）的专用 profile 非常有用。它们也可以用于设置角色或限制用户。

本地 profile 提供了一种方便的方法，可以为受限制的应用程序启动的实用程序提供专门的限制。它们像标准 profile 一样指定，但嵌入在父 profile 中，并以 profile 关键字开头

/parent/profile {
   ...
   profile /local/profile {
      ...
   }
}

要转换为本地 profile，请使用 cx 规则（请参阅 第 30.12.2 节，“离散本地 profile 执行模式 (cx)”）或命名 profile 转换（请参阅 第 30.12.7 节，“命名 profile 转换”）。

AppArmor “hats” 是具有某些附加限制的本地 profile，并且隐式规则允许使用 change_hat 进行转换。有关详细描述，请参阅 第 34 章，使用 ChangeHat profile 您的 Web 应用程序。

AppArmor 提供了 change_hat 和 change_profile 规则，用于控制域转换。change_hat 通过在 profile 中定义 hats 来指定，而 change_profile 规则引用另一个 profile，并以关键字 change_profile 开头

change_profile -> /usr/bin/foobar,

change_hat 和 change_profile 都提供了一种应用程序引导的 profile 转换，而无需启动单独的应用程序。change_profile 提供了一种单向转换，可以在任何已加载的 profile 之间进行转换。change_hat 提供了一种可返回的父子转换，应用程序可以从父 profile 切换到 hat profile，并在稍后时间提供正确的密钥后返回到父 profile。

change_profile 最适合在应用程序经过受信任的设置阶段后，可以降低其权限级别的情况。在启动阶段映射或打开的任何资源仍然可用，但新的 profile 限制了新资源的打开，并限制了启动前打开的某些资源。具体来说，内存资源仍然可用，而 capability 和文件资源（如果它们未内存映射）可以受到限制。

change_hat 最适合在应用程序运行虚拟机或解释器，而解释器不直接访问应用程序资源的情况（例如 Apache 的 mod_php）。由于 change_hat 将返回密钥存储在应用程序的内存中，因此权限降低阶段不应直接访问内存。同样重要的是，文件访问应该正确分离，因为 hat 可以限制对文件句柄的访问，但不会关闭它。如果应用程序进行缓冲并提供对使用缓冲打开的文件的访问，则内核可能看不到对这些文件的访问，因此新 profile 无法限制这些访问。

警告：域转换的安全性

与通过 exec 进行的域转换相比，change_hat 和 change_profile 域转换的安全性较低，因为它们不会影响进程的内存映射，也不会关闭已打开的资源。

抽象是按常见应用程序任务分组的包含。这些任务包括访问身份验证机制、访问名称服务例程、常见的图形要求和系统记账。这些抽象中列出的文件特定于命名的任务。需要其中一个文件的程序还需要抽象文件中列出的其他文件（具体取决于本地配置和程序的特定要求）。在 /etc/apparmor.d/abstractions 中找到抽象。

program-chunks 目录 (/etc/apparmor.d/program-chunks) 包含特定于程序套件的某些配置文件块，通常在套件外部没有用处，因此从不建议在配置文件向导 (aa-logprof 和 aa-genprof) 中将它们用于配置文件。目前，程序块仅适用于 postfix 程序套件。

tunables 目录 (/etc/apparmor.d/tunables) 包含全局变量定义。在配置文件中使用时，这些变量会扩展为一个可以更改的值，而无需更改整个配置文件。将应提供给每个配置文件的所有可调参数定义添加到 /etc/apparmor.d/tunables/global。

配置文件标志控制相关配置文件的行为。您可以通过手动编辑配置文件来添加配置文件标志，请参见以下语法

/path/to/profiled/binary flags=(list_of_flags) {
  [...]
}

您可以使用逗号“,”或空格“ ”分隔多个标志。有三种基本的配置文件标志：模式、相对和附加标志。

模式 标志是 complain（允许非法访问并记录）。如果省略，配置文件将处于 enforce 模式（强制执行策略）。

提示

将整个配置文件置于 complain 模式的更灵活方法是在 /etc/apparmor.d/force-complain/ 目录中创建指向配置文件文件的符号链接。

ln -s /etc/apparmor.d/bin.ping /etc/apparmor.d/force-complain/bin.ping

相对 标志是 chroot_relative（表示配置文件相对于 chroot 而不是命名空间）或 namespace_relative（默认，路径相对于 chroot 外部）。它们是互斥的。

附加 标志由两对互斥标志组成：attach_disconnected 或 no_attach_disconnected（确定解析为命名空间外部的路径名是否附加到根，这意味着它们在开头具有“/”字符），以及 chroot_attach 或 chroot_no_attach（控制在 chroot 环境中访问 chroot 外部但在命名空间内的文件时路径名生成）。

AppArmor 允许在配置文件中使用保存路径的变量。使用全局变量使您的配置文件可移植，并使用局部变量为路径创建快捷方式。

全局变量何时派上用场的一个典型示例是网络场景，其中用户主目录安装在不同的位置。与其在所有受影响的配置文件中重写主目录的路径，您只需更改变量的值。全局变量在 /etc/apparmor.d/tunables 下定义，需要通过包含语句提供。在此用例中找到变量定义 (@{HOME} 和 @{HOMEDIRS}) 在 /etc/apparmor.d/tunables/home 文件中。

局部变量在配置文件的头部定义。这对于提供 chrooted 路径的基础很有用，例如

@{CHROOT_BASE}=/tmp/foo
/sbin/rsyslogd {
...
# chrooted applications
@{CHROOT_BASE}/var/lib/*/dev/log w,
@{CHROOT_BASE}/var/log/** w,
...
}

在以下示例中，虽然 @{HOMEDIRS} 列出了所有用户主目录的存储位置，但 @{HOME} 是一个空格分隔的主目录列表。 稍后，@{HOMEDIRS} 将通过两个新的特定位置扩展，这些位置存储着用户主目录。

@{HOMEDIRS}=/home/
@{HOME}=@{HOMEDIRS}/*/ /root/
[...]
@{HOMEDIRS}+=/srv/nfs/home/ /mnt/home/

注意

使用当前的 AppArmor 工具，变量只能在手动编辑和维护配置文件时使用。

配置文件名称可以包含通配符表达式，允许配置文件与多个二进制文件匹配。

以下示例对于 foo 二进制文件位于 /usr/bin 或 /bin 的系统有效。

/{usr/,}bin/foo { ... }

在以下示例中，当与可执行文件 /bin/foo 匹配时，/bin/foo 配置文件是精确匹配，因此会被选中。 对于可执行文件 /bin/fat，配置文件 /bin/foo 不匹配，并且由于 /bin/f* 配置文件比 /bin/** 更具体（更不通用），因此选择了 /bin/f* 配置文件。

/bin/foo { ... }

/bin/f*  { ... }

/bin/**  { ... }

有关配置文件名称通配符示例的更多信息，请参阅 AppArmor 的 man 页面，man 5 apparmor.d,，章节 Globbing。

命名空间用于提供不同的配置文件集。 例如，一个用于系统，另一个用于 chroot 环境或容器。 命名空间是分层的——命名空间可以看到其子项，但子项无法看到其父项。 命名空间名称以冒号 : 开头，后跟一个字母数字字符串，一个尾随冒号 : 和一个可选的双斜杠 //，例如

:childNameSpace://

加载到子命名空间的配置文件在其命名空间名称前缀（从父级的角度查看）

:childNameSpace://apache

可以通过 change_profile API 或命名配置文件转换进入命名空间

/path/to/executable px -> :childNameSpace://apache

配置文件可以有一个名称和一个附加规范。 这允许使用逻辑名称的配置文件，该名称对用户/管理员来说比包含模式匹配的配置文件名称更有意义（请参阅 第 30.6.3 节，“模式匹配”）。 例如，默认配置文件

/** { ... }

可以命名为

profile default /** { ... }

此外，可以使用模式匹配命名的配置文件。 例如

/usr/lib64/firefox*/firefox-*bin { ... }

可以命名为

profile firefox /usr/lib64/firefox*/firefox-*bin { ... }

别名规则提供了一种替代方法来操作配置文件路径映射，以适应特定站点的布局。 它们是使用变量的路径重写的另一种形式，并且在变量解析之后完成。 别名规则表示将具有相同源前缀的规则视为位于目标前缀的规则。

alias /home/ -> /usr/home/

所有具有与 /home/ 匹配的前缀的规则都提供对 /usr/home/ 的访问。 例如

/home/username/** r,

也允许访问

/usr/home/username/** r,

别名提供了一种无需重写规则即可重新映射规则的快速方法。 它们使源路径仍然可访问——在我们的示例中，别名规则使 /home/ 下的路径仍然可访问。

使用 alias 规则，您可以同时指向多个目标。

alias /home/ -> /usr/home/
alias /home/ -> /mnt/home/

注意

使用当前的 AppArmor 工具，别名规则只能在手动编辑和维护配置文件时使用。

提示

将全局别名定义插入到文件 /etc/apparmor.d/tunables/alias 中。

允许程序对资源具有读取访问权限。 读取访问权限对于 shell 脚本和其他解释内容是必需的，并确定执行进程是否可以 core dump。

允许程序对资源具有写入访问权限。 如果要取消链接（删除）文件，则文件必须具有此权限。

允许程序写入文件的末尾。 与 w 模式相反，追加模式不包括覆盖数据、重命名或删除文件的能力。 追加权限通常与需要能够写入日志文件但不得操纵日志文件中任何现有数据的应用程序一起使用。 由于追加权限是与写入模式相关的权限的子集，因此不能同时使用 w 和 a 权限标志，并且它们是互斥的。

应用程序可以获取文件锁。 AppArmor 的早期版本允许锁定文件，如果应用程序可以访问它们。 通过使用单独的文件锁定模式，AppArmor 确保锁定仅限于需要文件锁定的文件，并加强安全性，因为锁定可用于多种拒绝服务攻击场景。

链接模式调解对硬链接的访问。 创建链接时，目标文件必须与创建的链接具有相同的访问权限（但目标不需要链接访问权限）。

链接模式授予链接到任意文件的权限，前提是链接具有目标授予的权限的子集（子集权限测试）。

/srv/www/htdocs/index.html rl,

通过指定源和目标，链接对规则提供了对硬链接创建方式的更大控制。 链接对规则默认情况下不强制标准规则链接权限所需的链接子集权限测试。

link /srv/www/htdocs/index.html -> /var/www/index.html

要强制规则需要测试，请使用 subset 关键字。 以下规则是等效的

/var/www/index.html l,
link subset /var/www/index.html -> /**,

注意

目前，YaST 和命令行工具不支持链接对规则。 手动编辑您的配置文件以使用它们。 使用工具更新此类配置文件是安全的，因为链接对条目不受影响。

如果未指定 allow 前缀是可选的，并且在未使用 deny 关键字（请参阅 第 30.7.9 节，“拒绝规则”）时，则表示它。

allow file /example r,
allow /example r,
allow network,

您还可以使用可选的 file 关键字。 如果您省略它并且没有其他以关键字开头的规则类型，例如 network 或 mount，则会自动推断它。

file /example/rule r,

等效于

/example/rule r,

以下规则授予对所有文件的访问权限

file,

等于

/** rwmlk,

文件规则可以使用前导或尾随权限。 权限不应指定为尾随权限，而应在规则的开头使用。 这很重要，因为它使文件规则的行为与其他规则类型一样。

/path rw,            # old style
rw /path,            # leading permission
file rw /path,       # with explicit 'file' keyword
allow file rw /path, # optional 'allow' keyword added

文件规则可以扩展，以便它们可以根据用户是文件的所有者（fsuid 需要与文件的 uid 匹配）来有条件地扩展。 为此，将 owner 关键字放在规则前面。 所有者条件规则像常规文件规则一样累积。

owner /home/*/** rw

当使用带有链接规则的文件所有权条件时，所有权测试是对目标文件进行的，因此用户必须拥有该文件才能链接到它。

注意：常规文件规则的优先级

所有者条件规则被视为常规文件规则的子集。 如果常规文件规则与所有者条件文件规则重叠，则这些规则将被合并。 考虑以下示例。

/foo r,
owner /foo rw,  # or w,

规则合并——结果是每个人都有 r，只有所有者才有 w。

提示

要解决除了文件所有者以外的每个人，请使用关键字 other。

owner /foo rw,
other /foo r,

拒绝规则可用于注释或抑制已知的拒绝。 配置文件生成工具不会询问使用拒绝规则处理的已知拒绝。 这种拒绝不会出现在被拒绝时的审核日志中，从而使日志文件保持精简。 如果这不是期望的，请在拒绝条目前面放置关键字 audit。

也可以将拒绝规则与允许规则结合使用。 这允许您指定一个广泛的允许规则，然后减去一些已知不应允许的几个文件。 拒绝规则也可以与所有者规则结合使用，以拒绝由用户拥有的文件。 以下示例允许对用户目录中的所有内容进行读/写访问，但禁止对 .ssh/ 文件的写入访问

deny /home/*/.ssh/** w,
owner /home/*/** rw,

拒绝规则的广泛使用通常不鼓励，因为它使理解配置文件内容更加困难。 但是，明智地使用拒绝规则可以简化配置文件。 因此，工具仅生成拒绝特定文件的配置文件，并且不使用拒绝规则中的通配符。 手动编辑您的配置文件以添加使用通配符的拒绝规则。 使用工具更新此类配置文件是安全的，因为拒绝条目不受影响。

此模式要求为在 AppArmor 域转换处执行的资源定义一个离散的安全配置文件。如果没有定义配置文件，则拒绝访问。

与 Ux、ux、px 和 ix 不兼容。

与 Px 类似，但不是搜索全局配置文件集，Cx 仅搜索当前配置文件的本地配置文件。此配置文件转换提供了一种方法，使应用程序可以为辅助应用程序提供替代配置文件。

注意：离散本地配置文件执行模式 (cx) 的限制

当前，Cx 转换仅限于顶级配置文件，不能在帽子和子配置文件中使用。此限制将在未来删除。

与 Ux、ux、Px、px、cx 和 ix 不兼容。

允许程序在不应用任何 AppArmor 配置文件的情况下执行该资源。当受限制的程序需要执行特权操作（例如重新启动机器）时，此模式很有用。通过将特权部分放在另一个可执行文件中，并授予未限制的执行权限，可以绕过对所有受限制的进程施加的强制约束。允许 root 进程变为未限制意味着它可以更改 AppArmor 策略本身。有关约束内容，请参阅 apparmor(7) 手册页。

此模式与 ux、px、Px 和 ix 不兼容。

仅在特殊情况下使用执行模式的小写版本——px、cx、ux。它们不会清除环境变量（例如 LD_PRELOAD）。因此，调用域可能对被调用资源产生过大的影响。仅当子进程绝对 必须 以未限制的模式运行并且必须使用 LD_PRELOAD 时，才使用这些模式。使用这些模式的任何配置文件都提供的安全性微乎其微。请自行承担风险。

ix 阻止在配置程序执行命名程序时正常的 AppArmor 域转换。相反，执行的资源继承当前配置文件。

当受限制的程序需要调用另一个受限制的程序而无需获得目标配置文件的权限或失去当前配置文件的权限时，此模式很有用。由于 ix 执行不会更改权限，因此没有用于清除环境的版本。

与 cx、ux 和 px 不兼容。隐含 m。

此模式允许使用 mmap(2) 的 PROT_EXEC 标志将文件映射到内存中。此标志将页面标记为可执行。在某些体系结构上，它用于提供不可执行的数据页面，这会使利用尝试复杂化。AppArmor 使用此模式来限制行为良好的程序（或在强制执行不可执行内存访问控制的体系结构上的所有程序）可以将哪些文件用作库，以限制给定给 ld(1) 和 LD_PRELOAD、LD_LIBRARY_PATH 给定给 ld.so(8) 的无效 -L 标志。

默认情况下，px 和 cx（以及它们的干净执行变体）将转换为名称与可执行文件名称匹配的配置文件。使用命名配置文件转换，您可以指定要转换到的配置文件。如果多个二进制文件需要共享单个配置文件，或者它们需要使用与名称指定的配置文件不同的配置文件，这很有用。命名配置文件转换可与 cx、Cx、px 和 Px 一起使用。当前每个配置文件最多允许十二个命名配置文件转换。

命名配置文件转换使用 -> 来指示需要转换到的配置文件的名称

/usr/bin/foo
{
  /bin/** px -> shared_profile,
  ...
  /usr/*bash cx -> local_profile,
  ...
  profile local_profile
  {
    ...
  }
}

注意：正常转换和命名转换之间的区别

在使用通配符时，正常转换提供“一对多”关系——/bin/** px 转换为 /bin/ping、/bin/cat 等，具体取决于正在运行的程序。

命名转换提供“多对一”关系——无论名称如何，匹配规则的所有程序都转换为指定的配置文件。

命名配置文件转换在日志中显示为具有模式 Nx。要更改到的配置文件的名称列在 name2 字段中。

px 和 cx 转换指定硬依赖关系——如果指定的配置文件不存在，则执行失败。通过继承备用，执行成功但继承当前配置文件。要指定继承备用，ix 与 cx、Cx、px 和 Px 组合成模式 cix、Cix、pix 和 Pix。

/path Cix -> profile_name,

或者

Cix /path -> profile_name,

其中 -> profile_name 是可选的。

如果您添加未限制的 ux 模式，则结果模式为 cux、CUx、pux 和 PUx。这些模式允许在找不到指定的配置文件时回退到“未限制”。

/path PUx -> profile_name,

或者

PUx /path -> profile_name,

其中 -> profile_name 是可选的。

备用模式也可以与命名配置文件转换一起使用。

在选择 Px、Cx 或 Ux 执行模式之一时，请注意以下环境变量在子进程继承它之前会被从环境中删除。因此，依赖于这些变量的应用程序或进程如果在应用于它们的配置文件中带有 Px、Cx 或 Ux 标志，将不再起作用

您可以对规则使用“safe”和“unsafe”关键字，而不是使用执行模式的大小写修饰符。例如

/example_rule Px,

与以下任何一个相同

safe /example_rule px,
safe /example_rule Px,
safe px /example_rule,
safe Px /example_rule,

规则

/example_rule px,

与以下任何一个相同

unsafe /example_rule px,
unsafe /example_rule Px,
unsafe px /example_rule,
unsafe Px /example_rule,

“safe”/“unsafe”关键字是互斥的，可以在文件规则的“owner”关键字之后使用，因此规则关键字的顺序是

[audit] [deny] [owner] [safe|unsafe] file_rule