如何使用 AppArmor 限制自定义程序的权限？
美国、香港服务器
如何使用 AppArmor 限制自定义程序的权限？
12-19 来源:
使用 AppArmor 限制自定义程序（如自研二进制程序、脚本、编译后的可执行文件）的核心是基于 “最小权限原则” 编写配置文件，精准开放程序必需的资源访问（文件、网络、系统调用等），拒绝所有未显式允许的操作。以下是适配 Ubuntu 24.04 的完整流程，以 “自定义二进制程序 /usr/local/bin/myapp” 和 “Python 脚本 /opt/my_script.py” 为例详细说明：
一、前置准备
1. 确认 AppArmor 状态（Ubuntu 24.04 默认启用）
bash
运行
sudo systemctl status apparmor # 输出 active (running) 即为正常
aa-status # 查看已加载的规则（确认无冲突）
2. 梳理自定义程序的核心依赖
先明确程序的 “必需资源”，避免权限不足导致程序崩溃：
资源类型 排查方法
可执行文件路径 which myapp 或 ls -l /opt/my_script.py（记录绝对路径）
读写目录 查看程序代码 / 配置，确认数据存储、日志输出目录（如 /opt/myapp/data/）
依赖库 二进制程序：ldd /usr/local/bin/myapp；Python 脚本：pip list（依赖库路径）
网络行为 程序是否需要联网（TCP/UDP）、仅本地通信还是访问外网
系统调用 程序是否需要特殊权限（如绑定端口、修改系统时间）
示例（二进制程序 myapp）：
bash
运行
# 查看二进制程序依赖库
ldd /usr/local/bin/myapp
# 输出示例：依赖 /lib64/ld-linux-x86-64.so.2、/usr/lib/libc.so.6 等
二、核心步骤：配置 AppArmor 规则
步骤 1：创建配置文件（命名规则）
AppArmor 配置文件存于 /etc/apparmor.d/，命名为「程序绝对路径替换 / 为 .」：
二进制程序 /usr/local/bin/myapp → 配置文件 usr.local.bin.myapp
Python 脚本 /opt/my_script.py → 配置文件 opt.my_script.py
bash
运行
# 以二进制程序为例，创建配置文件
sudo nano /etc/apparmor.d/usr.local.bin.myapp
步骤 2：编写通用规则模板（最小权限）
以下是适配自定义程序的核心规则模板，注释标注 “必选 / 可选”，可按需删减：
apparmor
# 1. 关联程序可执行文件（必选：与实际路径完全一致）
/usr/local/bin/myapp {
# ========== 基础系统资源（必选：程序运行依赖） ==========
# 系统核心库（只读，二进制程序必需）
/lib/** r,
/usr/lib/** r,
/lib64/** r,
/usr/lib64/** r,
# 程序自身可执行权限（mr=读+内存执行）
/usr/local/bin/myapp mr,
# ========== 业务目录（按需开放：仅程序必需的目录） ==========
# 数据存储目录（rwk=读+写+文件锁定，根据业务调整）
/opt/myapp/data/** rwk,
# 日志目录（日志写入需 rwk）
/var/log/myapp/** rwk,
# 临时文件目录（可选：程序若需临时文件则开放）
/tmp/ rw,
/tmp/myapp.* rwk,
# ========== 网络权限（按需限制：默认禁止，需则开放） ==========
# 仅允许本地 TCP 通信（如 127.0.0.1 端口）
# network tcp addr=127.0.0.1,
# 允许所有 TCP 通信（外网访问需则开放）
# network tcp,
# 禁止所有网络（默认推荐）
deny network all,
# ========== 系统权限（最小化：仅开放必需的capability） ==========
# 示例：允许绑定 80/443 端口（需则加）
# capability net_bind_service,
# 拒绝所有管理员级权限（必选：防提权）
deny capability sys_admin,
deny capability setuid,
deny capability setgid,
# ========== 敏感目录（显式拒绝：必选，防越权） ==========
deny /etc/shadow r, # 拒绝读取密码文件
deny /root/** rw, # 拒绝访问root目录
deny /home/** rw, # 拒绝访问用户目录
deny /bin/bash r, # 拒绝调用shell（防提权）
# ========== 兜底规则（必选：拒绝所有未显式允许的操作） ==========
deny /** w, # 禁止写入所有未授权目录
}
步骤 3：Python 脚本的规则适配（特殊场景）
若限制的是 Python 脚本（如 /opt/my_script.py），需额外开放 Python 解释器和依赖库路径，配置文件示例：
apparmor
/opt/my_script.py {
# Python 解释器（必选：根据系统Python版本调整）
/usr/bin/python3.12 mr,
# Python 标准库（只读）
/usr/lib/python3.12/** r,
# 第三方依赖库（如 pip 安装的包，按需添加）
/usr/local/lib/python3.12/dist-packages/** r,
# 脚本自身（只读）
/opt/my_script.py r,
# 业务目录（按需开放）
/opt/my_script/data/** rwk,
/var/log/my_script.log rwk,
# 禁止网络+敏感目录+兜底规则（同二进制程序）
deny network all,
deny /etc/shadow r,
deny /** w,
}
三、加载并生效规则
步骤 1：编译配置文件（检查语法错误）
bash
运行
# -v 显示详细信息，-W 提示警告，确保无语法错误
sudo apparmor_parser -vW /etc/apparmor.d/usr.local.bin.myapp
若报错 “syntax error”，检查配置文件格式（如逗号、花括号是否匹配）。
步骤 2：加载规则并重启程序
bash
运行
# 重新加载 AppArmor 服务
sudo systemctl reload apparmor
# 重启自定义程序（使规则生效，以 systemd 管理的程序为例）
sudo systemctl restart myapp
# 若为手动运行的程序，先终止再重启
pkill myapp && /usr/local/bin/myapp
步骤 3：切换规则模式（调试→生产）
complain（投诉模式）：仅记录违规日志，不拦截（调试阶段必用）；
enforce（强制模式）：拦截违规行为并记录日志（生产环境推荐）。
bash
运行
# 先切换为 complain 模式调试
sudo aa-complain /etc/apparmor.d/usr.local.bin.myapp
# 调试完成后切换为 enforce 模式
sudo aa-enforce /etc/apparmor.d/usr.local.bin.myapp
四、验证规则是否生效
方法 1：查看已加载的规则
bash
运行
aa-status | grep myapp
# 输出示例：/usr/local/bin/myapp (complain) → 模式生效
方法 2：测试越权访问（核心验证）
故意让程序尝试访问未授权资源，查看 AppArmor 拦截日志：
编写测试代码（模拟越权）：
bash
运行
# 示例：修改 myapp 代码，尝试写入 /root/test.txt
echo "echo "test" > /root/test.txt" >> /opt/myapp/test.sh
/usr/local/bin/myapp # 运行程序触发越权操作
查看拦截日志（Ubuntu 24.04 日志存于 /var/log/syslog）：
bash
运行
sudo grep -i apparmor /var/log/syslog | grep myapp
# 输出示例（说明拦截成功）：
# apparmor="DENIED" operation="open" profile="/usr/local/bin/myapp" name="/root/test.txt" pid=1234 comm="myapp" requested_mask="w" denied_mask="w"
五、调试与排错（关键！避免程序崩溃）
新规则易因 “权限不足” 导致程序崩溃，优先通过 complain 模式收集合法权限：
步骤 1：收集被拒绝的合法权限
bash
运行
# 运行程序并触发所有正常业务操作（如读写数据、输出日志）
/usr/local/bin/myapp
# 查看 AppArmor 日志，提取被拒绝的合法路径
sudo grep -i apparmor /var/log/syslog | grep myapp
示例日志（程序需要访问 /opt/myapp/config.ini 但未开放）：
plaintext
apparmor="DENIED" operation="open" profile="/usr/local/bin/myapp" name="/opt/myapp/config.ini" pid=5678 comm="myapp" requested_mask="r" denied_mask="r"
步骤 2：补充缺失的权限
在配置文件中添加对应路径的权限：
apparmor
/opt/myapp/config.ini r, # 补充配置文件只读权限
重新编译加载规则：
bash
运行
sudo apparmor_parser -r /etc/apparmor.d/usr.local.bin.myapp
常见问题及解决
问题现象 原因 解决方法
程序启动失败 遗漏系统库 / 自身路径权限 检查日志，补充 /lib/** r 或程序自身 mr 权限
日志无法写入 未添加 k（文件锁定）权限 将 /var/log/myapp/** rw 改为 rwk
Python 脚本导入模块失败 未开放依赖库路径 添加 /usr/lib/python3.12/** r
网络连接失败 未开放 network 权限 按需添加 network tcp
六、生产环境最佳实践
最小权限原则：
仅开放程序 “必需” 的资源（如无需网络则 deny network all，无需 /tmp 则删除对应权限）；
禁止程序调用 shell（deny /bin/bash r），防止攻击者通过程序提权。
规则固化：
修改配置后，执行 apparmor_parser -r [配置文件] 重新加载，避免重启 AppArmor 服务；
备份配置文件（cp /etc/apparmor.d/usr.local.bin.myapp /backup/），防止系统更新覆盖。
日志监控：
定期检查 /var/log/syslog 中的 AppArmor 日志，发现异常访问（如程序尝试读取 /etc/shadow）；
可将 AppArmor 日志单独存储（修改 /etc/rsyslog.d/apparmor.conf），便于审计。
容器化程序适配：
若自定义程序运行在 Docker 中，可复用 Docker 自带的 AppArmor 模板（/etc/apparmor.d/docker），在模板基础上自定义规则。
七、禁用 / 删除规则（如需）
bash
运行
# 1. 临时禁用（切换为 complain 模式）
sudo aa-complain /etc/apparmor.d/usr.local.bin.myapp
# 2. 永久删除规则
sudo rm /etc/apparmor.d/usr.local.bin.myapp
sudo systemctl reload apparmor
# 3. 验证删除结果
aa-status | grep myapp # 无输出则删除成功
三二互联专业提供香港VPS,美国VPS主机,香港云服务器租用等业务香港美国到大陆CN2 GIA速度最快
