# AppArmor 入门 Demo（demo1）技术说明

> 环境：Ubuntu 24.04 x86_64（阿里云 ECS），内核 6.8.0-124-generic，
> AppArmor parser 4.0.1，profile ABI 4.0。
> 运行日期：2026-09-03，最终报告见同目录 `report.txt`。

## 1. Demo 目标

用一个最小可复现的例子演示 AppArmor（Linux 内核的强制访问控制 / MAC 模块）最核心的三个行为：

| # | 场景 | 预期 |
|---|------|------|
| 1 | 访问 profile 中**显式允许**的路径 | 放行 |
| 2 | 访问 profile 中 `deny` 显式禁止的路径 | **静默拒绝**（EACCES，无审计日志） |
| 3 | 访问 profile 中**完全没有提及**的路径 | 拒绝 + 内核记录 `DENIED` 审计日志 |

同时覆盖两种可执行体形态：

- **ELF 二进制**（`demo_app.c` 编译出的 `demo_app`）—— profile 直接 attach 到二进制路径；
- **Shell 脚本**（`demo_shell.sh`）—— AppArmor 不认识"脚本"，attach 的是**解释器**，转场（transition）发生在 exec `/bin/bash` 时。

## 2. 文件清单

```
demo1/
├── demo_app.c       # C 测试程序：3 个文件访问探针
├── demo_shell.sh    # bash 测试脚本：3 个同类探针
├── profile.elf      # demo_app 的 AppArmor profile
├── profile.script   # demo_shell.sh 的 AppArmor profile
├── run.sh           # 一键运行脚本（需 root）
└── report.txt       # 运行产物：完整执行报告
```

## 3. 测试程序设计

`demo_app.c` 与 `demo_shell.sh` 是同一组探针的两种实现：

```c
/* 探针1: 白名单 —— profile 允许 rw，应当成功 */
fopen("/tmp/demo_elf.log", "w");
/* 探针2: 显式 deny —— deny /etc/shadow r，静默拒绝 */
fopen("/etc/shadow", "r");
/* 探针3: 未提及路径 —— 隐式默认拒绝，拒绝并记录 DENIED 日志 */
fopen("/tmp/demo_forbidden.log", "w");
```

三个探针分别命中 AppArmor 白名单规则的"允许"、`deny` 关键字、以及 enforce 模式下的默认拒绝（default deny）。

## 4. Profile 逐行解读

### 4.1 `profile.elf`（ELF 二进制）

```
abi <abi/4.0>,

/home/fnzhang/Project/examples/AppArmor/demo1/demo_app flags=(enforce) {
    /home/fnzhang/Project/examples/AppArmor/demo1/demo_app r,
    /lib/** rm,
    /usr/lib/** rm,
    /usr/lib64/** rm,
    /etc/ld.so.cache r,
    /tmp/demo_elf.log rw,
    deny /etc/shadow r,
}
```

| 语法元素 | 含义 |
|----------|------|
| `abi <abi/4.0>,` | 声明 profile 所依据的规则 ABI 版本。不写会按 parser 默认（本机 4.0）并可能告警；显式写出可保证规则语义在不同 parser 版本间稳定 |
| `路径 { ... }` | **匿名 attach 写法**：profile 的 attachment 点就是这段路径本身，进程 exec 该路径时自动套用此 profile，无需 `px` 转场规则 |
| `flags=(enforce)` | 强制模式：违规即拒绝。对比 `flags=(complain)` 只记日志不拦截（调试用） |
| `... r,` | `r` = read；文件规则末尾必须有逗号 |
| `/lib/** rm` | `**` 跨目录通配；`rm` = read + mmap（动态库加载需要 m 权限） |
| `/etc/ld.so.cache r` | 动态链接器要读的缓存 |
| `/tmp/demo_elf.log rw` | 探针 1 的白名单 |
| `deny /etc/shadow r` | 探针 2 的显式拒绝。`deny` 的语义是**无声拒绝且不产生审计日志**——与"没写这条规则时 enforce 模式的默认拒绝（有日志）"是两种不同行为 |

### 4.2 `profile.script`（Shell 脚本）

```
abi <abi/4.0>,

/home/fnzhang/Project/examples/AppArmor/demo1/demo_shell.sh flags=(enforce) {
    /home/fnzhang/Project/examples/AppArmor/demo1/demo_shell.sh r,
    /bin/bash rm,
    /usr/bin/bash rm,
    ...
    /usr/bin/cat rm,
    /tmp/demo_sh.log rw,
    deny /etc/shadow r,
}
```

关键点：

1. **attach 点是脚本路径，但真正受约束的是解释器进程**。内核 exec 脚本时会切换到 `/bin/bash` 执行；AppArmor 通过脚本头部的 `#!` 识别原始路径，把 profile 转场给 bash。所以：
   - 脚本自身要 `r`（bash 要读它）；
   - `/bin/bash` 要 `rm`（exec 解释器 + mmap）；
   - 脚本里用到的**每个外部命令**（这里是 `cat`）都要单独授权 —— 本 demo 故意**不**给 `cat` 授权 `/etc/shadow` 的读取，让 `cat` 本身可以 exec、但读文件时被拒，从而演示"子进程继承 profile 约束"。
2. `@{HOME}` 这类**变量需要先 include tunables 才能用**（`#include <tunables/global>`）。本 profile 为保持自包含、便于教学阅读，直接写绝对路径。

## 5. 运行方式

```bash
cd demo1
chmod +x run.sh demo_shell.sh
sudo sh run.sh        # 必须以 root 运行：装载/卸载 profile 需要特权
```

`run.sh` 流程：

```
Pre-cleanup  ─ apparmor_parser -R 卸载可能残留的旧 profile（幂等，容错）
Step1        ─ gcc 编译 demo_app.c
Step2        ─ apparmor_parser -Q 只做语法校验，不装载
Step3        ─ cp 到 /etc/apparmor.d/ 并 apparmor_parser -r -W 装载（enforce）
              └ 之后 sleep 6 等 audit ratelimit 窗口恢复（见 §7）
Step4/5      ─ 分别运行 ELF 与脚本，收集 3 个探针的输出
Step6        ─ aa-status --json 过滤出两个 demo profile 的模式
Step7        ─ dmesg 过滤 apparmor="DENIED" 的审计记录
Step8        ─ 卸载 profile、删除 /etc/apparmor.d 下文件、清理 /tmp 探针文件
```

## 6. 实测结果（report.txt 摘录）

**ELF：**

```
[probe1] write /tmp/demo_elf.log: ALLOWED          ← 白名单放行
[probe2] open /etc/shadow: Permission denied       ← deny 规则拒绝
[probe3] open /tmp/demo_forbidden.log: Permission denied  ← 默认拒绝
-rw-r--r-- 1 root root 13 /tmp/demo_elf.log        ← 允许的写确实落盘
```

**脚本：**

```
[probe1] write /tmp/demo_sh.log: ALLOWED
demo_shell.sh: line 8: /usr/bin/cat: Permission denied        ← cat 可 exec，读 shadow 被拒
demo_shell.sh: line 12: /tmp/demo_forbidden.log: Permission denied
```

**aa-status：**

```
/home/fnzhang/Project/examples/AppArmor/demo1/demo_app: enforce
/home/fnzhang/Project/examples/AppArmor/demo1/demo_shell.sh: enforce
```

**内核审计日志（dmesg）：**

```
apparmor="DENIED" operation="mknod" profile="...demo_app"
    name="/tmp/demo_forbidden.log" requested_mask="c" denied_mask="c"
apparmor="DENIED" operation="exec" profile="...demo_shell.sh"
    name="/usr/bin/cat" requested_mask="x" denied_mask="x"
```

注意 DENIED 日志里**只有 probe3 和 `cat` 的事件，没有 `/etc/shadow`**——这正是 `deny` 规则（静默）与默认拒绝（记录日志）的区别在日志层面的直接证据。

## 7. 踩坑记录（本 demo 调通过程中实际遇到）

1. **profile 路径写死**：最初 profile 里是 `/home/fnzhang/aa_demo/...`（目录已不存在）。AppArmor 按可执行文件**绝对路径**匹配，路径变了 profile 就完全不生效。改 profile 前先确认二进制的实际路径。
2. **`profile 名 flags=() 路径 {}` 是非法语法**：flags 必须放在 attachment 之后或用独立 `flags` 行；正确写法是 `路径 flags=(enforce) { ... }` 或 `profile 名 路径 flags=(enforce) { ... }`。非法语法会导致 `systemctl reload apparmor` 整体失败，且报错信息不在终端上、只在 `journalctl -u apparmor` 里。
3. **`@{HOME}` 未声明报错**：`Found reference to variable HOME, but is never declared`——不带 `#include <tunables/global>` 时必须用绝对路径。
4. **audit ratelimit 吞掉 DENIED 日志**：`systemctl reload apparmor` 会重载系统全部 200+ 个 profile，产生海量 `STATUS` 审计事件，触发内核 `printk_ratelimit`（`kauditd_printk_skb: xxx callbacks suppressed`），把随后几秒内 demo 真正的 DENIED 事件一并丢弃。解法：
   - 装载/卸载单条 profile 直接用 `apparmor_parser -r -W <file>` / `apparmor_parser -R <file>`，不要 `systemctl reload`；
   - 装载后 `sleep 6`（默认 ratelimit 窗口 5 秒）再触发拒绝。
5. **`deny` 规则不产生日志是设计行为**：想在日志里看到拒绝事件，应使用"不写规则、靠 enforce 默认拒绝"的方式（demo 的 probe3 即为此设计）。
6. **脚本 profile 授权对象**：给脚本写 profile 时，脚本内用到的外部命令都要逐个授权；漏掉会在运行时以 `Permission denied` 暴露。

## 8. 常用命令速查

```bash
# 查看 AppArmor 是否启用
cat /sys/module/apparmor/parameters/enabled     # Y
aa-status                                       # 已装载 profile 列表与模式

# 装载 / 替换 / 卸载单条 profile（-W 同时写缓存）
sudo apparmor_parser -r -W /etc/apparmor.d/xxx
sudo apparmor_parser -R /etc/apparmor.d/xxx

# 仅语法校验
apparmor_parser -Q /path/to/profile

# 查看某个进程当前的 profile
cat /proc/<pid>/attr/current

# 查看拒绝日志
sudo dmesg | grep 'apparmor="DENIED"'
sudo journalctl -k | grep apparmor

# 临时把某 profile 切到 complain 模式排查问题
sudo aa-complain /etc/apparmor.d/xxx
sudo aa-enforce /etc/apparmor.d/xxx
```

## 9. 与 SELinux 的对比（一句话版）

| | AppArmor | SELinux |
|---|----------|---------|
| 标签对象 | **路径**（文件路径 + 进程可执行路径） | inode 标签（label） |
| 规则粒度 | 每应用一个 profile，白名单易读 | 策略全局统一，类型强制（TE） |
| 学习成本 | 低，`aa-logprof` 可从日志生成规则 | 高 |
| 适用发行版 | Ubuntu / Debian / SUSE | RHEL / Fedora / Android |

两者都是 LSM（Linux Security Module）钩子实现，内核只能启用其一（`CONFIG_LSM` 决定）。