Linux smack模块介绍

Linux 的 Smack（Simplified Mandatory Access Control Kernel）是一种 Linux 内核安全模块，属于 LSM（Linux Security Module）框架的实现之一。它的设计目标是提供强制访问控制功能，同时力求简单性和易用性，主要面向嵌入式系统和资源受限环境。

以下是 Smack 的核心概念和介绍：

  1. 核心思想：标签（Labels）

    • Smack 的核心是为系统中的所有主体（Subject - 通常是进程）和对象（Object - 文件、目录、套接字、管道、设备等）分配一个简单的、人类可读的文本字符串作为安全标签。
    • 例如：System, Application, User, Internet, Secret。
    • 标签名称通常很短（最多 255 个字符，但实践中都很简洁），便于配置和理解。

  2. 访问控制规则：

    • Smack 的规则基于主体标签对对象标签的访问权限。
    • 规则非常直接：一个带有标签 A 的进程（主体）能否访问（读、写、执行等）一个带有标签 B 的对象（文件、目录等）？
    • 访问决策由一个简单的访问规则列表决定。这个列表定义了哪些主体标签可以以何种方式（rwxat - 读、写、执行、追加、锁定/传输）访问哪些对象标签。
    • 关键规则类型：
      • A B rwxat：标签为 A 的进程可以读、写、执行、追加、锁定/传输标签为 B 的对象。
      • A B r--：标签为 A 的进程只能读标签为 B 的对象。
      • * B r：任何主体标签（* 是通配符）都可以读标签为 B 的对象。
      • A * w：标签为 A 的进程可以写任何对象标签。
    • 规则存储在 /smack/load 或 /smack/load2（通常通过 smackload 工具加载）和 /smack/accesses（运行时规则）中。

  3. 关键特性与机制：

    • 传输（Transmutation） (t): 当进程创建新文件或目录时，新对象的标签通常继承父目录的标签。但如果进程对父目录拥有 t 权限，新对象的标签则会被设置为进程自身的标签。这对于在共享目录（如 /tmp）中创建私有文件非常有用。
    • 地板规则（Floor Rule）： 一个特殊的标签（默认是 _），代表系统中最不受信任的级别。任何没有明确规则的访问，如果涉及 _ 标签的对象，默认会被拒绝（除非明确配置了允许 * _ ... 的规则）。这实现了“默认拒绝”的安全原则。
    • 帽子规则（Hat Rule / Capability）： 允许进程在执行特定任务时临时“戴上”另一个标签（帽子）。这提供了更精细的权限控制，类似于能力机制。
    • 仅执行（Execute Only）: Smack 支持 x 权限独立于 r 权限，允许执行一个文件而不需要读取其内容。
    • CIPSO 网络标签： Smack 可以通过 CIPSO（Commercial IP Security Option）在 IP 数据包中传递 Smack 标签，从而将 MAC 策略扩展到网络通信。接收方内核可以根据数据包中的 Smack 标签进行访问控制决策。
    • 文件系统支持： Smack 标签作为扩展属性存储在支持扩展属性的文件系统上（如 ext4, xfs, btrfs 等）。属性名通常是 security.SMACK64, security.SMACK64EXEC, security.SMACK64MMAP, security.SMACK64TRANSMUTE。
    • 与用户空间交互： 通过 /smack 伪文件系统（通常挂载在 /sys/fs/smackfs）进行配置和管理。工具集 smack-utils 提供了如 chsmack, smackaccess, smackload 等命令来操作标签、测试访问权限和加载规则。

  4. 与 SELinux 和 AppArmor 的比较：

    • SELinux： 功能极其强大和灵活，但策略非常复杂，配置和学习曲线陡峭。基于类型强制（TE）、角色访问控制（RBAC）和多级安全（MLS/MCS）。策略文件庞大。
    • AppArmor： 基于路径的 MAC。为特定应用程序定义配置文件（profile），规定该程序可以访问哪些路径和资源。更直观，易于为单个应用配置，但策略范围通常限定在配置了 profile 的程序上。
    • Smack： 基于标签的 MAC，核心模型非常简单（主体标签 -> 对象标签 -> 访问规则）。策略规则通常短小精悍，易于阅读和审计。设计目标就是简单和低开销。非常适合嵌入式、物联网和资源受限系统。

  5. 主要应用场景：

    • 嵌入式 Linux 系统： 路由器、智能家居设备、工业控制器等资源有限的设备。Smack 的低开销和简单性是其优势。
    • 高安全需求设备： 医疗设备、航空电子设备、关键基础设施控制器等需要严格隔离不同功能组件的场景。
    • 容器/沙箱环境： 可用于在共享主机上为容器或沙箱应用提供额外的隔离层。
    • 简化 MAC 需求： 当 SELinux 的复杂性成为负担，而 AppArmor 的路径限制不够灵活时，Smack 提供了一个基于标签的折中方案。
    • Android (早期探索)： Smack 曾被探索作为 Android 的 MAC 机制（SEAndroid 的前身概念之一），但最终 Android 选择了基于 SELinux 的 SEAndroid。

  6. 优点：

    • 简单： 概念模型和策略规则易于理解和编写。
    • 轻量： 内核实现和策略规则相对较小，运行时开销低。
    • 确定性： 访问决策基于明确的规则列表，行为可预测。
    • 灵活性： 标签可以灵活定义以适应不同的安全域需求。
    • 默认拒绝： 通过地板规则 (_) 实现，增强了安全性。

  7. 缺点/局限：

    • 功能相对有限： 不如 SELinux 功能丰富（缺少 RBAC, MLS/MCS 等高级特性）。
    • 社区和工具链较小： 用户、文档、工具和社区支持不如 SELinux 和 AppArmor 广泛。
    • 配置粒度： 虽然简单，但为大型复杂系统配置精细的策略可能需要管理大量标签和规则。
    • 依赖扩展属性： 标签存储依赖文件系统对扩展属性的支持。

总结：

Smack 是 Linux 内核中一个轻量级、基于标签的强制访问控制模块。其核心设计哲学是简单性和低开销。它通过为进程和资源分配文本标签，并定义清晰的规则来规定哪些标签的进程可以访问哪些标签的资源，实现了有效的安全隔离。虽然功能不如 SELinux 强大，社区也不如 SELinux 或 AppArmor 庞大，但 Smack 在嵌入式系统、物联网设备和需要简单有效 MAC 解决方案的场景中是一个非常有价值的选择。它的易读性、可审计性和低资源消耗是其关键优势。

smack是否对root无效

Smack 对 root 用户（或具有 CAP_MAC_OVERRIDE 能力的进程）是否有效，取决于其配置和内核能力：

  1. 默认情况下是有效的（即 root 也受约束）：

    • Smack 的核心设计原则之一是 “所有进程都受 MAC 约束”，这包括超级用户 root。
    • 即使一个进程拥有 root 用户身份或所有传统的 Linux 能力（CAP_SYS_ADMIN 等），如果没有通过 Smack 策略明确允许，它也无法访问标签不匹配的对象。
    • 这是 强制访问控制 (MAC) 区别于传统的 自主访问控制 (DAC) 的关键点。DAC 中 root 拥有至高无上的权限，而 MAC 的目标是在 DAC 之上 施加一层更严格的、基于策略的限制。

  2. 关键机制：CAP_MAC_OVERRIDE 能力

    • Linux 内核定义了一个特定的能力：CAP_MAC_OVERRIDE。
    • 如果一个进程拥有 CAP_MAC_OVERRIDE 能力，那么它可以绕过 Smack 的访问控制检查。
    • 默认情况下，root 用户拥有 所有 能力，包括 CAP_MAC_OVERRIDE。这意味着：
      • 初始状态： 一个以 root 身份启动的进程默认拥有 CAP_MAC_OVERRIDE，因此 可以绕过 Smack 策略。
    • 如何使 root 受约束： 为了使 root 进程真正受到 Smack 约束，必须主动移除其 CAP_MAC_OVERRIDE 能力。
      • 这通常在系统启动流程中、在加载 Smack 策略之后，由初始化脚本或安全框架完成。
      • 使用工具如 setcap 或编程接口 (cap_set_proc, prctl) 来移除进程的 CAP_MAC_OVERRIDE 能力。
      • 例如，一个设计良好的基于 Smack 的安全系统，会在关键的服务进程启动并加载策略后，移除 CAP_MAC_OVERRIDE 能力，确保后续所有进程（包括 root 进程）都遵守 MAC 策略。

  3. Smack 规则中的特殊处理：

    • Smack 规则本身也可以包含允许 root 或特定高特权标签的规则。
    • 例如，策略可能会定义一个标签 "@"（这是 Smack 中默认分配给 root 进程的初始标签，注意不是用户 root，而是进程标签）或 "System"，并配置规则允许 "@" 访问某些关键系统资源：
      • @ System rwxat
      • @ * rw (允许 root 进程读写任何标签的对象 - 慎用！这会严重削弱 MAC 效果)
    • 即使使用了这种规则，root 进程的访问仍需满足规则要求，它不能随意访问标签不允许的对象（除非拥有 CAP_MAC_OVERRIDE）。

  4. floor 规则 (_) 的影响：

    • Smack 的 floor 规则（默认标签 _）实现了“默认拒绝”。任何没有明确规则允许的访问都会被拒绝。
    • 这对 root 同样有效： 如果一个 root 进程（没有 CAP_MAC_OVERRIDE）试图访问一个标签为 _ 的对象，并且策略中没有 * _ ... 或类似规则明确允许这次访问，那么访问将被拒绝。这是 root 受约束的典型表现。

总结：

  • 设计上有效： Smack 的设计意图是约束包括 root 在内的所有进程。
  • CAP_MAC_OVERRIDE 是关键： 默认拥有该能力的 root 进程可以绕过 Smack。要使 Smack 对 root 真正有效，必须主动移除其 CAP_MAC_OVERRIDE 能力。 这是部署 Smack 进行强安全隔离的必要步骤。
  • 规则约束： 即使移除了 CAP_MAC_OVERRIDE，root 进程（或其持有的 Smack 标签）也必须遵守策略规则才能访问对象。floor 规则 (_) 会强制“默认拒绝”。
  • 策略配置： 策略编写者可以选择为 root 进程的标签（如 "@"）配置更宽松的规则，但这不等于不受约束，而是策略本身授予了特权。配置过于宽松的规则会降低安全性。

因此，简单回答“是否无效”不准确：

  • 如果系统没有移除 root 进程的 CAP_MAC_OVERRIDE 能力，那么 Smack 对 root 基本无效（root 可以绕过）。
  • 如果系统正确移除了 root 进程的 CAP_MAC_OVERRIDE 能力，那么 Smack 对 root 完全有效，root 进程必须严格遵守 Smack 策略规则进行访问。这是 Smack 实现真正强制隔离的标准做法。

selinux是否允许cap_sys_admin

SELinux 是否允许 CAP_SYS_ADMIN 能力，取决于具体的 SELinux 策略配置，而不是一概而论。SELinux 本身并不直接“允许”或“禁止” Linux 能力（Capabilities），而是通过策略控制哪些进程域（Domain）可以拥有（保留）哪些能力。

以下是关键点解析：

  1. Linux 能力 (Capabilities) 与 SELinux 的关系：

    • Linux 能力 (如 CAP_SYS_ADMIN) 是内核将传统 root 特权细分后的一组独立权限。拥有某个能力意味着进程可以执行该能力对应的特权操作。
    • SELinux 是一个强制访问控制 (MAC) 系统，它在传统的 自主访问控制 (DAC) 和 能力机制 (Capabilities) 之上施加额外的、基于策略的安全层。
    • SELinux 不取代能力机制，而是管理进程可以拥有哪些能力。

  2. SELinux 如何控制能力：

    • SELinux 策略定义了一系列 allow 规则，明确指定：
      • 哪个 **源域 (Source Domain - 通常是进程的上下文类型)**，
      • 可以在哪个 目标域 (Target Domain - 通常也是进程自身的域，用于能力控制) 上，
      • 拥有哪些 **能力类 (Capability Class)**。
    • 策略语言中控制能力的关键语句是 allow 规则结合 capability 类：
      1
      allow source_domain target_domain:capability capability_name;
    • 例如，要允许 httpd_t 域（Apache 进程）拥有 cap_sys_admin 能力：
      1
      allow httpd_t httpd_t:capability sys_admin;
    • 如果 SELinux 策略中没有明确允许某个域拥有 cap_sys_admin，那么即使该进程的 UID 是 root 或者通过其他方式（如文件能力）尝试获取它，SELinux 也会在安全检查阶段拒绝该能力相关的操作。 操作会被记录到审计日志 (audit.log/dmesg)。

  3. CAP_SYS_ADMIN 的特殊性：

    • CAP_SYS_ADMIN 是一个极其强大且宽泛的能力，常被称为“新的 root”。它包含了许多敏感操作权限，例如：
      • 挂载/卸载文件系统
      • 配置磁盘配额
      • 配置安全模块（如 SELinux 本身的状态）
      • 执行系统管理任务（如 sethostname, setdomainname）
      • 执行特权 ioctl 命令
      • 修改内核模块参数 (sysctl)
      • 访问 /proc/kcore 等
    • 由于它的强大性，在严格的 SELinux 策略（如 targeted 或自定义安全策略）中，默认通常不会授予普通应用程序域（如 user_t, unconfined_t 以外的域） CAP_SYS_ADMIN 能力。 只有特定的、可信的系统管理域（如 sysadm_t, init_t, kernel_t 或某些容器运行时域）才可能被策略允许拥有它。

  4. 与 unconfined_t 域的关系：

    • 在发行版（如 RHEL/CentOS/Fedora）默认的 targeted 策略中，有一个特殊的域 unconfined_t。
    • 分配给 unconfined_t 域的进程（通常是登录用户的 shell 及其启动的 GUI 应用）不受 SELinux 对能力的限制。如果这些进程以 root 身份运行，它们将拥有所有能力，包括 CAP_SYS_ADAdmin。
    • 这是 CAP_SYS_ADMIN 在默认配置下看起来“被允许”的主要原因，但本质是因为这些进程在 unconfined_t 域，绕过了 SELinux 的能力限制，而不是策略明确允许了该能力本身。 对于严格限制在非 unconfined_t 域（如 httpd_t, dbusd_t, container_t）的进程，策略通常会显式拒绝 CAP_SYS_ADMIN。

  5. 检查与诊断：

    • 查看进程上下文和能力： 使用 ps -eZ 查看进程的 SELinux 上下文，使用 getpcaps 查看进程的实际有效能力集。
    • 查看 SELinux 拒绝日志： 如果 SELinux 阻止了进程使用 CAP_SYS_ADMIN，会在 /var/log/audit/audit.log 或 journalctl 中生成 AVC (Access Vector Cache) 拒绝消息，明确提到 capability 类和 sys_admin。
    • 查询策略： 使用 sesearch 工具检查当前策略是否允许某个域拥有 sys_admin 能力：
      1
      sesearch -A -s httpd_t -c capability -p sys_admin
      (将 httpd_t 替换为目标域) 如果找到 allow 规则，则表示策略允许。

总结：

  • SELinux **不直接“允许” CAP_SYS_ADMIN**，而是通过策略规则 控制哪些进程域可以拥有（保留）该能力。
  • **默认情况下，在严格限制的域（非 unconfined_t）中，策略通常禁止普通进程拥有 CAP_SYS_ADMIN**，因为它过于强大。
  • 只有策略中明确包含 allow source_domain source_domain:capability sys_admin; 规则的域，其进程才能有效拥有并使用 CAP_SYS_ADMIN 能力。
  • unconfined_t 域中的进程不受此限制，但这削弱了 SELinux 提供的安全边界。最佳实践是将需要特权的服务限制在最小权限域中，并按需精细授权能力（甚至避免授予整个 CAP_SYS_ADMIN，而是授权其子集如 cap_dac_override, cap_net_admin 等，如果策略支持）。

因此，一个进程能否使用 CAP_SYS_ADMIN，最终取决于它运行的 SELinux 域以及加载的策略中是否包含允许该域拥有该能力的规则。SELinux 的存在使得即使 root 进程（UID 0）也可能无法使用 CAP_SYS_ADMIN，如果策略禁止其所在域拥有该能力。

smack模块是否允许CAP_SYS_ADMIN和CAP_MAC_OVERRIDE

Smack 模块对 CAP_SYS_ADMIN 和 CAP_MAC_OVERRIDE 这两个 Linux 能力（Capabilities）的处理方式截然不同，其核心逻辑源于 Smack 的设计目标和在 Linux 安全体系中的角色：

  1. CAP_MAC_OVERRIDE：这是 Smack 的“生死开关”

    • 直接影响 Smack 访问控制： CAP_MAC_OVERRIDE 能力是 Linux 内核为所有 LSM (Linux Security Module) 定义的一个通用能力。它的唯一作用就是允许进程绕过 LSM 实施的强制访问控制 (MAC) 检查。
    • Smack 明确受其控制： 对于 Smack 来说：
      • 拥有 CAP_MAC_OVERRIDE 的进程： 可以完全绕过 Smack 的标签访问控制规则。 无论 Smack 策略如何配置，无论进程标签是什么，无论对象标签是什么，拥有此能力的进程都能访问任何对象（只要通过基础的 DAC 检查）。这使得 Smack 对该进程无效。
      • 没有 CAP_MAC_OVERRIDE 的进程： 必须严格遵守 Smack 策略规则。访问是否允许完全由进程标签、对象标签和 /smack/accesses 文件中定义的规则决定。
    • root 的默认状态： 因为 root 用户默认拥有所有能力（包括 CAP_MAC_OVERRIDE），所以 默认情况下，root 进程可以绕过 Smack。要使 Smack 对 root 生效，必须显式移除其 CAP_MAC_OVERRIDE 能力（通常在系统启动的安全初始化阶段完成）。
    • 总结：CAP_MAC_OVERRIDE 是 Smack 的“豁免令牌”。拥有它，Smack 规则失效；没有它，Smack 规则强制生效。

  2. CAP_SYS_ADMIN：Smack 通常不关心（不直接干预）

    • Smack 的职责范围： Smack 是一个 强制访问控制 (MAC) 模块。它的核心职责是管理基于标签的主体（进程）对客体（文件、IPC 等）的访问权限（读、写、执行等）。它不负责管理传统的 Linux 能力机制。
    • 独立的安全层： Linux 能力 (Capabilities) 是内核将传统 root 特权细分后的一组独立权限（例如 CAP_SYS_ADMIN 允许挂载文件系统、执行系统管理等）。能力检查是发生在 DAC 检查之后、LSM (MAC) 检查之前的另一个独立的安全层。
    • Smack 的默认行为：
      • Smack 本身不会授予或剥夺 CAP_SYS_ADMIN 或其他任何传统 Linux 能力。
      • 一个进程能否执行需要 CAP_SYS_ADMIN 的操作，首先取决于它是否拥有该能力（由内核能力子系统决定，基于进程的凭证和能力集）。
      • 只有在进程通过了能力检查（拥有 CAP_SYS_ADMIN）并且通过了基础的 DAC 检查之后，Smack 的 MAC 检查（基于标签和规则）才会被触发。
    • Smack 的约束依然存在：
      • 即使一个进程拥有 CAP_SYS_ADMIN 能力，如果它没有 CAP_MAC_OVERRIDE 能力，那么它试图访问一个受 Smack 保护的对象时，仍然必须遵守 Smack 策略规则。
      • 例如：一个拥有 CAP_SYS_ADMIN 的进程 A 试图写入一个标签为 Secret 的文件。如果 Smack 规则中没有允许进程 A 的标签写入 Secret 标签对象的规则（A Secret w），并且进程 A 没有 CAP_MAC_OVERRIDE，写入操作将被 Smack 拒绝，即使它拥有 CAP_SYS_ADMIN。
    • 总结：CAP_SYS_ADMIN 允许进程执行特定的特权操作，但 Smack 控制的是这些操作最终能否访问到特定的目标对象。拥有 CAP_SYS_ADMIN 并不赋予进程绕过 Smack MAC 规则的权利（除非它同时拥有 CAP_MAC_OVERRIDE）。

关键对比表格：

能力 对 Smack 的影响 Smack 是否管理该能力？ 默认 root 状态影响 Smack 有效性
CAP_MAC_OVERRIDE 直接控制 Smack 是否生效：
• 有它： Smack 规则被绕过，访问控制失效。
• 无它： Smack 规则强制生效。		 是 (核心相关) 是 (默认拥有，导致 Smack 失效)
CAP_SYS_ADMIN 不直接影响 Smack 规则：
• 允许执行特权操作，但这些操作访问受 Smack 保护的对象时，仍需遵守 Smack 规则 (除非同时有 CAP_MAC_OVERRIDE)。		 否 (独立机制) 否 (不影响 Smack 规则应用)

结论：

  • CAP_MAC_OVERRIDE 是 Smack 的“克星”： 拥有此能力意味着进程可以无视所有 Smack 安全策略。禁用此能力（尤其是对 root）是部署有效 Smack 防护的强制性步骤。
  • CAP_SYS_ADMIN 与 Smack 基本无关： Smack 不管理传统 Linux 能力。拥有 CAP_SYS_ADMIN 可以让进程尝试执行特权操作，但这些操作能否成功访问到受 Smack 保护的具体资源，仍然严格受 Smack 标签和规则的限制（除非该进程同时拥有 CAP_MAC_OVERRIDE）。管理 CAP_SYS_ADMIN 是系统能力配置和潜在的其他安全机制（如 Seccomp）的职责。

因此，在加固一个使用 Smack 的系统时：

  1. 首要任务是移除关键进程（包括 root 进程）的 CAP_MAC_OVERRIDE 能力，确保 Smack 真正生效。
  2. 其次才是根据需要，遵循最小权限原则，**精细控制进程（包括 root 进程）拥有的传统能力如 CAP_SYS_ADMIN**，以限制其可执行的特权操作范围。Smack 会在这些特权操作尝试访问具体对象时，继续施加其基于标签的访问控制。

Linux Apparmor机制介绍

Linux AppArmor（Application Armor）是一种基于路径的强制访问控制（MAC） 安全模块，集成在 Linux 内核中（通过 LSM 框架实现）。它的核心思想是为应用程序定义安全配置文件（Profile），限制应用程序的行为（如文件访问、网络权限、能力使用等），从而最小化攻击面，即使应用程序存在漏洞或被入侵，也能限制其破坏范围。

以下是 AppArmor 的核心机制与特点介绍：

1. 核心设计理念：基于路径的配置 (Path-Based)

  • 与 SELinux 的差异： SELinux 使用安全上下文标签（如 user_u:role_r:type_t），而 AppArmor 直接使用文件系统路径和程序名来定义资源访问规则。
  • 优势：
    • 直观易理解： 管理员无需理解复杂的标签系统，直接看到 /usr/bin/firefox 可以访问 ~/.mozilla/** 等。
    • 易于配置和审计： 配置文件通常更短，规则含义清晰。
    • 对现有系统改动小： 不需要给文件系统打标签（XATTR），迁移或备份更简单。
  • 局限： 对硬链接、挂载点、动态路径（如用户主目录 ~）的处理有时需要额外规则或抽象。

2. 核心概念：配置文件 (Profile)

  • 作用对象： 每个受保护的应用程序（或二进制文件）需要定义一个 Profile。
  • 内容： 包含一系列允许（allow）或拒绝（deny）的规则，定义该程序可以：
    • 访问哪些文件/目录（读 r、写 w、执行 x、内存映射 m、链接 l 等）。
    • **使用哪些 Linux 能力 (Capabilities)**（如 cap_net_bind_service）。
    • 进行哪些网络操作（协议 tcp/udp，端口，套接字类型 inet/unix）。
    • **挂载/卸载文件系统 (mount/umount)**。
    • 发送/接收 Unix 域套接字消息。
    • 访问哪些 DBus 总线和方法。
    • 发送/接收哪些信号 (signal)。
    • 执行哪些子程序 (px/ux/ix/cx/pix)。
  • 位置： 配置文件通常存储在 /etc/apparmor.d/ 目录下，文件名通常与程序名相关（如 usr.bin.firefox）。

3. 配置文件语法示例 (简化版)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
# /etc/apparmor.d/usr.bin.myapp
abi <abi/3.0> # 声明兼容的 ABI 版本

#include <tunables/global> # 包含全局调优文件

/usr/bin/myapp { # 为 /usr/bin/myapp 定义 Profile
  #include <abstractions/base> # 包含基础抽象规则（常用路径集合）

  # 文件访问规则
  /etc/myapp/*.conf r, # 可读配置文件
  /var/log/myapp.log w, # 可写日志文件
  /var/lib/myapp/** rwk, # 可读写其数据目录下所有内容
  /tmp/myapp-*.tmp rw, # 可读写特定格式的临时文件
  deny /etc/passwd r, # 明确拒绝读取敏感文件

  # 能力规则
  capability net_bind_service, # 允许绑定低端口 (<1024)
  deny capability sys_admin, # 明确拒绝强大的系统管理能力

  # 网络规则
  network inet tcp, # 允许 IPv4 TCP
  network inet6 udp, # 允许 IPv6 UDP
  deny network netlink raw, # 拒绝 raw netlink 访问

  # 执行规则
  /usr/lib/myapp/plugins/* ix, # 执行插件（继承当前 Profile）
  /bin/bash px -> sanitized_shell, # 执行 bash 并切换到 sanitized_shell Profile
  deny /usr/bin/rm mrix, # 禁止执行 rm 命令（包括内存映射等）

  # DBus 规则 (可选)
  dbus send bus=session path=/com/example/MyApp interface=com.example.MyApp.Interface member=DoAction,

  # 挂载规则 (V8.0+ 支持更细粒度)
  mount options=(ro) /dev/sdb1 -> /mnt/backup/,

  # 信号规则
  signal (receive) peer=/usr/sbin/cron,
}

4. 关键特性与机制

  • 执行模式 (Enforcement Modes):
    • enforce 模式： 策略强制执行，违反规则的访问会被阻止并记录日志。提供实际防护。
    • complain 模式 (或 learning 模式)： 策略仅记录违规行为而不阻止。用于策略开发、测试和调试。aa-logprof 工具可分析日志并生成新的规则建议。
  • 抽象 (Abstractions)： 预定义的通用规则集合（如 abstractions/base, abstractions/nameservice），可通过 #include 包含到 Profile 中，避免重复编写常见规则（如访问 /etc/hosts, /etc/passwd(只读), /usr/share/ 等）。
  • 变量 (Variables)： 在全局调优文件（tunables/）或 Profile 中定义变量（如 @{HOME} = /home/*），提高 Profile 的可读性和可维护性。规则中可使用 @{VAR} 引用。
  • 子配置文件 (Child Profiles) 和 转换 (Transitions)：
    • 允许程序在执行另一个程序时切换到不同的 Profile (px, cx, pix 规则)。
    • 例如：Web 服务器主进程 (apache2) 的 Profile 可以规定其子进程 /usr/lib/apache2/modules/mod_php.so 切换到更严格的 mod_php Profile。
  • 网络控制： 可精细控制应用程序的网络访问（协议、端口、地址族）。新版 AppArmor (V3+) 支持强大的网络规则。
  • 能力控制： 明确允许或拒绝应用程序使用特定的 Linux Capabilities（如 cap_net_raw, cap_sys_admin）。
  • DBus 控制： 控制应用程序通过 DBus 与其他进程通信的能力（发送/接收消息，访问特定接口和方法）。
  • 文件系统挂载控制： 控制应用程序挂载、卸载文件系统的权限和选项（需要较新内核和 AppArmor 版本）。
  • 信号控制： 控制应用程序发送或接收信号的能力。

5. 管理工具

  • aa-status： 查看 AppArmor 状态、加载的 Profile 及其模式。
  • aa-enable / aa-disable： 全局启用/禁用 AppArmor（不常用，通常管理单个 Profile）。
  • apparmor_parser： 核心工具，用于**加载 (-r)、卸载 (-R)、重载 (-r)、检查 (-p) ** Profile 到内核。
  • aa-genprof / aa-easyprof： 引导式生成 Profile。aa-genprof 在 complain 模式下运行目标程序，监控其行为并生成初始规则草案。
  • aa-logprof： 分析 /var/log/audit/audit.log 或 /var/log/syslog 中的 AppArmor 拒绝日志，更新现有 Profile（添加缺失规则）。是策略调优的主要工具。
  • aa-complain / aa-enforce： 将单个 Profile 设置为 complain 或 enforce 模式。
  • aa-notify： 实时通知用户空间的 AppArmor 拒绝事件。

6. 优势

  • 易用性： 基于路径的配置更直观，学习曲线比 SELinux 平缓。
  • 低侵入性： 无需文件系统标签，易于集成到现有系统。
  • 应用为中心： 专注于保护特定应用程序（尤其是网络服务），部署灵活。
  • 强大的学习工具： aa-genprof 和 aa-logprof 极大简化了策略开发。
  • 广泛支持： 被 Ubuntu、Debian、openSUSE 等主流发行版默认集成并预装大量 Profile。

7. 局限与挑战

  • 路径依赖： 对硬链接、挂载命名空间 (pivot_root/chroot)、动态路径的处理可能复杂。
  • 覆盖范围： 主要保护配置了 Profile 的应用程序。未配置 Profile 的程序不受约束（除非使用 unconfined 抽象或默认策略）。不如 SELinux 的全面系统策略（strict 策略）。
  • 复杂性增长： 为大型复杂应用（如浏览器、办公套件）编写精细的 Profile 依然可能很复杂。
  • 特权进程限制： 对 root 进程的限制取决于 Profile 的严格程度。如果 Profile 允许 capability sys_admin 或未限制特权操作，root 进程仍可能拥有强大权限（但 AppArmor 本身对 root 有效）。

8. 典型应用场景

  • 服务器加固： 保护 Web 服务器 (apache2, nginx)、数据库 (mysqld, postgres)、DNS 服务器 (bind9) 等关键服务。
  • 桌面应用沙箱化： 限制浏览器 (firefox, chromium)、邮件客户端、PDF 阅读器等，防止恶意文档或网页利用漏洞破坏系统。
  • 容器安全： 作为主机层防御，为容器引擎 (docker, containerd) 或其管理的容器进程添加额外约束。
  • 多租户环境： 限制不同用户运行的应用程序的权限。
  • 符合性要求： 满足安全标准（如 PCI DSS, HIPAA）中关于应用程序最小权限的要求。

9. 与 SELinux 的简要对比

特性 AppArmor SELinux
配置模型 基于路径 基于安全上下文标签 (Type Enforcement)
策略目标 应用为中心 (保护特定程序) 系统为中心 (定义全局类型/角色/用户)
学习曲线 较平缓，工具链 (aa-genprof, aa-logprof) 优秀 较陡峭，策略语言复杂
文件系统要求 无需 文件系统标签 (XATTR) 需要 文件系统支持扩展属性 (XATTR)
默认部署 Ubuntu, Debian, openSUSE 等 RHEL, CentOS, Fedora, Android (SEAndroid)
精细度 优秀 (文件, 能力, 网络, DBus, 挂载, 信号) 极强 (TE, RBAC, MLS/MCS, 条件语句)
管理复杂性 相对较低 (尤其对单个应用) 相对较高
处理动态环境 路径依赖有时是挑战 标签机制更灵活

总结

AppArmor 是一个强大且注重易用性的 Linux 强制访问控制系统。它通过为应用程序定义基于路径的安全配置文件，有效限制应用程序的权限和能力，遵循最小权限原则，显著提升系统安全性，尤其在防范应用层漏洞利用方面效果显著。其直观的配置语法和优秀的策略生成/调优工具 (aa-genprof, aa-logprof) 使其成为管理员加固服务器和桌面环境的实用选择。虽然它在处理极端复杂的系统级策略时可能不如 SELinux 灵活，但在应用沙箱化和服务加固领域，它提供了极佳的易用性和安全性的平衡。