AppArmor 是轻量级路径导向的 MAC 机制，需启用模块、加载 profile 并验证生效；配置须白名单、精确路径、明确权限与能力；调试用 complain 模式，生产环境必须 enforce。
AppArmor 是 Linux 内核中轻量、路径导向的强制访问控制（MAC）机制，适合快速为单个进程定制最小权限策略。它不依赖复杂的标签系统，配置直观、日志清晰，特别适用于 Ubuntu、Debian、SUSE 及容器环境。配置核心在于：写对 profile、加载到位、验证生效——三步缺一不可。
确认 AppArmor 已启用并运行
别跳过这一步。很多“权限失败”问题其实源于 AppArmor 根本没在工作。
- 检查模块是否加载：
cat /sys/module/apparmor/parameters/enabled—— 输出 Y 才算启用 - 查看服务状态：
systemctl status apparmor，确保 active (running) - 列出已加载 profile：
aa-status，确认目标程序路径（如/usr/bin/zapret）出现在 “profiles are loaded” 列表中 - 查拒绝记录最直接：
sudo dmesg | grep -i "apparmor.*denied"或sudo journalctl --dmesg | grep -i denied
编写精准的 AppArmor 配置文件
配置文件放在 /etc/apparmor.d/ 下，命名规则是将可执行文件路径中的 / 替换为 .（例如 /usr/bin/activate-linux → usr.bin.activate-linux）。内容必须遵循白名单原则，只放真正需要的规则。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
基础结构：以
#include <tunables/global>开头，主体用大括号包裹 -
文件权限：用
r（读）、w（写）、rw、log（日志专用）、ix（继承执行）等后缀；路径支持通配符（如/tmp/** rw），但避免/var/**这类宽泛写法 -
能力限制：用
capability声明，如capability sys_admin,—— 不加则默认禁止 -
网络控制：用
network inet tcp,或network inet6 udp,明确协议与类型，不写即禁用 -
关键细节：规则末尾必须有逗号；路径需写绝对路径；注释用
#；配置文件本身无执行权限
加载策略并验证运行效果
改完配置不会自动生效，必须手动重载并重启进程。
- 语法检查并加载：
sudo apparmor_parser -r /etc/apparmor.d/usr.bin.zapret（-r表示替换） - 重启目标服务：
sudo systemctl restart zapret（或直接启动二进制） - 确认 profile 已 enforce：
sudo aa-status | grep zapret，输出应含 enforce 字样 - 复现操作并观察日志：若仍有拒绝，立即查
dmesg或journalctl -t kernel，根据报错路径追加规则 - 调试技巧：临时切 complain 模式收全行为
sudo aa-complain /usr/bin/zapret，再用sudo aa-logprof生成建议（但结果需人工收紧）
常见陷阱与安全建议
配置容易，配得安全才难。以下几点直接影响防护实效。
-
拒绝“一刀切”规则：如
/etc/** r或/usr/** mr会大幅削弱策略价值，审计时易被标为高危 - 区分 enforce 与 complain：生产环境必须是 enforce；complain 仅用于调试，不阻断任何操作
-
密钥与配置文件分开对待：AppArmor 允许读
/etc/ssl/private/my.key，不代表该文件可设为 644 —— 文件系统权限（chmod）仍需保持 600 -
容器场景注意路径映射：宿主机路径在容器内挂载后，profile 中写的仍是容器视角的路径（如
/run/php/php8.2-fpm.sock） - 定期 review：当应用升级、配置目录变更、新增日志路径时，必须同步更新 profile，否则服务可能静默失败
