24 配置文件组件和语法 #

默认的 AppArmor 配置文件将按其名称关联到程序，因此，配置文件的名称必须与其要限制的应用程序的路径相匹配。

/usr/bin/foo {
...
}

每当未受限的进程执行 /usr/bin/foo 时，就会自动使用此配置文件。

未关联的配置文件不会驻留在文件系统名称空间中，因此不会自动关联到应用程序。未关联的配置文件的名称前面带有关键字 profile。您可以自由选择配置文件名称，但存在以下限制：名称不得以 : 或 . 字符开头。如果名称包含空格，必须将它括在引号中。如果名称以 / 开头，则将该配置文件视为标准配置文件，因此以下两个配置文件是相同的：

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

系统永远不会自动使用未关联的配置文件，也不能通过 Px 规则将其他配置文件转换为未关联的配置文件。需使用命名配置文件转换（请参见第 24.12.7 节 “命名配置文件转换”）或 change_profile 规则（请参见第 24.2.5 节 “更改规则”）将其关联到程序。

一般不应由系统范围的配置文件（例如 /bin/bash）限制的系统实用程序的专用配置文件适合采用未关联的配置文件。它们还可用于设置角色或限制用户。

本地配置文件可让您方便地针对受限制应用程序启动的实用程序提供专门的限制。其指定方式类似于标准配置文件，不过，它们嵌入于父配置文件中，并以 profile 关键字开头：

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

要转换为本地配置文件，请使用 cx 规则（请参见第 24.12.2 节 “离散本地配置文件执行模式 (Cx)”）或命名配置文件转换（请参见第 24.12.7 节 “命名配置文件转换”）。

AppArmor“帽子”属于本地配置文件，它们存在一些额外的限制，以及允许使用 change_hat 转换到这些配置文件的隐式规则。有关详细说明，请参见 第 28 章 “使用 ChangeHat 构建 Web 应用程序的配置文件”。

AppArmor 提供了 change_hat 和 change_profile 规则，用于控制域转换。change_hat 通过在配置文件中定义帽子来指定，而 change_profile 规则会引用另一个配置文件，并以关键字 change_profile 开头：

change_profile -> /usr/bin/foobar,

change_hat 和 change_profile 都提供应用程序导向的配置文件转换，而无需启动单独的应用程序。change_profile 在装载的任何配置文件之间均提供通用的单向转换。change_hat 提供可回转的父子转换，其中，应用程序可从父配置文件切换到帽子配置文件，如果它提供正确的机密密钥，则稍后可恢复为父配置文件。

change_profile 最适合用于应用程序需要经历可信设置阶段，随后可以降低其特权级别的情况。在启动阶段映射或打开的任何资源在配置文件发生更改后仍可访问，但新配置文件将限制新资源的打开，甚至会限制在转变之前打开的某些资源。具体而言，在可以限制功能和文件资源（前提是它们未经过内存映射）的情况下，内存资源仍然可用。

change_hat 最适合用于应用程序需运行不提供应用程序资源（例如 Apache 的 mod_php）直接访问途径的虚拟机或解释器的情况。由于 change_hat 将返回机密密钥储存在应用程序的内存中，因此在特权降级阶段，不应具有直接访问内存的权限。正确分隔文件访问权限也很重要，因为帽子可以限制对文件句柄的访问，但不会关闭文件句柄。如果应用程序在进行缓冲并通过缓冲提供对所打开文件的访问，内核可能看不到对这些文件的访问，因此新配置文件不会限制此类访问。

警告：域转换的安全性

change_hat 和 change_profile 域转换不如通过执行完成的域转换安全，因为它们不会影响进程的内存映射，也不会关闭已打开的资源。

抽象是按常见应用程序任务分组的 include。这些任务包括访问身份验证机制、访问名称服务例程、一般的图形要求以及系统统计。这些抽象中列出的文件特定于命名任务。需要其中某个文件的程序通常也需要抽象文件中列出的其他文件（取决于程序的本地配置和具体要求）。/etc/apparmor.d/abstractions 中提供了抽象。

program-chunks 目录 (/etc/apparmor.d/program-chunks) 中包含一些专用于程序套件的配置文件块，这些块在套件外部一般没有作用，因此，配置文件向导（aa-logprof 和 aa-genprof）从不建议在配置文件中使用这些配置文件块。目前，程序块仅适用于 postfix 程序套件。

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

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

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

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

模式标志为 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 下定义，需要通过 include 语句来使用。/etc/apparmor.d/tunables/home 文件中提供了此用例的变量定义（@{HOME} 和 @{HOMEDIRS}）。

局部变量在配置文件的头部定义。这样便于提供 chroot 路径的基础，例如：

@{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 5 apparmor.d 以及“通配”一节。

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

:childNameSpace://

装载到子名称空间的配置文件以其名称空间名称为前缀（从父项的角度看）：

:childNameSpace://apache

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

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

配置文件可以有一个名称和一个附件规范。这样，您便可为配置文件指定一个比包含模式匹配（请参见第 24.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 /home/ -> /usr/home/
alias /home/ -> /mnt/home/

注意

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

提示

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

允许程序拥有读取资源的权限。必需对外壳脚本和其他解释内容授予读取访问权限，该权限确定正在执行的进程是否可以进行核心转储。

允许程序拥有写入资源的权限。将被取消链接（删除）的文件必须拥有此权限。

允许程序写入到文件的末尾。与 w 模式相反，追加模式不包含重写数据、重命名或去除文件的功能。追加权限通常用于需要能够写入日志文件，但不应该能够操作日志文件中任何现有数据的应用程序。由于追加权限是与写入模式关联的权限的子集，w 和 a 权限标志不能结合使用，它们是互斥的。

应用程序可以采用文件锁。在以前的 AppArmor 版本中，如果应用程序有权访问文件，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（参见第 24.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。

此外，还可以将拒绝规则与允许规则结合使用。这样，您便可以先指定一条宽泛的允许规则，然后再去掉几个不应允许的已知文件。拒绝规则还可与拥有者规则结合使用来拒绝用户拥有的文件。下面的示例允许对 users 目录中的任何内容进行读写访问，但不允许对 .ssh/ 文件进行写入访问：

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

一般不建议大量使用拒绝规则，因为这会大大增加理解配置文件的作用的难度。不过，审慎使用拒绝规则可以简化配置文件。因此，工具只会生成拒绝特定文件的配置文件，而不会在拒绝规则中使用通配。要添加使用通配的拒绝规则，请手动编辑配置文件。使用工具更新此类配置文件是安全的操作，因为这种方式不会改动拒绝项。

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

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

类似于 Px，但 Cx 不搜索全局配置文件集，而只搜索当前配置文件的本地配置文件。应用程序可以通过这种配置文件转换获得助手应用程序的备用配置文件。

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

目前，Cx 转换仅对顶层配置文件适用，不能在帽子和子配置文件中使用。将来会去除这项限制。

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

允许程序执行资源，不对被执行的资源应用任何 AppArmor 配置文件。此模式可用于使被限制的程序能够执行需要特权的操作，如重新引导计算机等。通过在其他可执行文件中添加具有特权的部分并授予未受限的执行权限，您可以避开对全部受限制进程强制施加的限制。允许根进程不受限制意味着它可以更改 AppArmor 策略本身。有关限制内容的详细信息，请参见 apparmor(7) 手册页。

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

仅在非常特殊的情况下才使用小写形式的执行模式 — px、cx、ux。这些模式不会整理 LD_PRELOAD 等变量的环境。因此，调用域可能会对被调用资源产生过度影响。仅当绝对必须以非受限方式运行子项并且必须使用 LD_PRELOAD 时，才使用这些模式。任何使用此类模式的配置文件几乎都不会提供任何安全性。使用这些模式需自负后果。

当构建了配置文件的程序执行命名程序时，ix 会阻止 execve(2) 上的常规 AppArmor 域转换。相反，被执行的资源继承当前配置文件。

当被限制的程序需要调用其它被限制的程序时此模式非常实用，无须获得目标程序配置文件的权限或失去当前配置文件的权限。没有任何版本会整理环境，因为 ix 执行不会更改特权。

与 cx、ux 和 px 不兼容。隐式应用 m。

此模式允许使用 mmap(2) 的 PROT_EXEC 标志将文件映射到内存中。此标志将页面标示为可执行。某些体系结构使用此标志来提供不可执行的数据页面，这可以增加恶意利用的企图的困难度。AppArmor 使用此模式来限制可由行为正常的程序（或者强制实施不可执行内存访问控制的体系结构上的所有程序）用作库的文件，以及限制为 ld(1) 指定的无效 -L 标志以及为 ld.so(8) 指定的 LD_PRELOAD 和 LD_LIBRARY_PATH 所产生的影响。

默认情况下，px 和 cx（也包括其清洁执行变体）将转换到名称与可执行文件名称匹配的配置文件。使用命名配置文件转换，您可以指定要转换到的配置文件。如果多个二进制文件需要共享单个配置文件，或者这些二进制文件需要使用的配置文件不同于其名称指定的配置文件，此方法将非常有用。可以将命名配置文件转换与 cx、Cx、px 和 Px 结合使用。目前，每个配置文件仅可具有 12 个命名配置文件转换。

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

/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