apparmor profile 自动生成需工具辅助与人工验证闭环，核心是生成后经complain模式观察、补全再enforce；slimtoolkit轻量适配容器化服务，aa-logprof可基于真实日志反推规则；命名、内核启用、重启服务三者缺一不可；持续用aa-status和journalctl验证并迭代。
AppArmor profile 自动生成不是“一键 magic”，而是用工具辅助+人工验证的闭环过程。核心目标是减少手动编写时路径错配、权限漏放或过度授权的问题，关键在生成后必须进 complain 模式观察、补全、再 enforce。
用 SlimToolkit 快速生成基础 profile
SlimToolkit 是目前最轻量、适配性广的自动化工具，尤其适合容器化或新部署服务：
- 安装只需一行命令：
curl -L https://gitcode.com/gh_mirrors/slim18/slim/raw/main/scripts/install-slim.sh | sh - 对本地可执行文件生成 profile：
slim profile --target /usr/local/bin/myapp - 对 Docker 镜像生成（含 AppArmor 和 seccomp）：
slim profile --target myapp:latest - 生成结果默认存于
artifacts/apparmor-profile，内容已按 AppArmor 语法格式化，可直接放入/etc/apparmor.d/
用 aa-logprof 从运行日志反推规则
适用于已上线但无 profile 的服务，依赖真实访问行为，生成结果更贴近实际需求：
宝塔Linux面板11.8.1
下载
宝塔Linux面板11.8.1为官网当前正式版，新增AI建站能力并经过宝塔网站工程师深度调教，开放自定义AI功能API，同时对WAF进行界面重构和深度优化，提升拦截能力与运维效率。
- 先确保服务在 complain 模式下运行：
sudo aa-complain /etc/apparmor.d/usr.local.bin.myapp - 让服务正常工作一段时间（如完成一次完整业务流程）
- 运行
sudo aa-logprof，它会自动读取dmesg或journalctl中的 AppArmor DENIED 日志 - 交互式确认每条访问请求是否应允许——网络连接、配置文件读取、临时目录写入等都会逐条提示
- 完成后自动生成或更新对应 profile 文件，保留原有结构并追加必要规则
命名与加载前必须核对的三项
自动生成的 profile 再准，若加载失败就等于没生效。以下三步缺一不可：
-
文件名严格匹配可执行路径：比如程序在
/opt/app/bin/worker，profile 必须命名为/etc/apparmor.d/opt.app.bin.worker（斜杠全换为点） -
确认内核 AppArmor 已启用：执行
cat /sys/module/apparmor/parameters/enabled，输出Y才有效；若报错或为空，需检查内核启动参数是否含security=apparmor -
重启服务而非重载 profile：运行
sudo systemctl restart myapp.service，只有新启动的进程才会绑定策略；单纯apparmor_parser -r不会让已有进程受控
验证与迭代建议
生成不是终点，持续观察才是安全落地的关键：
- 用
aa-status查看 profile 是否已加载、进程是否处于 enforce 模式 - 检查
journalctl -k | grep apparmor，确认无意外 DENIED（尤其注意 GPU 设备、/dev/shm、socket 绑定等高频拦截点） - 首次 enforce 后建议保留 24 小时观察期，期间若服务异常，可快速切回 complain：
sudo aa-complain /etc/apparmor.d/xxx - 后续应用升级或功能扩展时，重复 logprof 流程补全新行为所需权限，避免策略僵化
