如何测试AppArmor配置文件的实际拦截效果？
美国、香港服务器
如何测试AppArmor配置文件的实际拦截效果？
12-22 来源:
测试 AppArmor 配置文件的实际拦截效果，核心是 “模拟正常业务操作” 和 “模拟违规越权操作”，对比两种场景下的行为结果与日志记录，验证配置是否既不影响业务，又能精准拦截危险操作。以下是分步骤的实操方案，以 MySQL 配置为例：
一、 测试前准备
确保配置已加载且处于强制模式强制模式（enforce）才会实际拦截违规操作，投诉模式（complain）仅记录不拦截，需先切换到强制模式：
bash
运行
# 切换到强制模式
sudo aa-enforce /usr/sbin/mysqld
# 重新加载配置文件
sudo apparmor_parser -v -r /etc/apparmor.d/usr.sbin.mysqld
# 重启目标进程（MySQL）使配置生效
sudo systemctl restart mysql
# 验证模式（输出 enforce 即为成功）
sudo aa-status | grep mysqld
明确配置的核心规则边界先梳理配置文件中的关键规则，明确 “允许的资源” 和 “禁止的资源”，测试时针对性验证：
允许的资源：如 /var/lib/mysql/** rwk（数据目录）、/etc/mysql/** r（配置目录）；
禁止的资源：如 /root/** rw（敏感目录）、/bin/bash r（执行 shell）、外网卡段连接。
二、 测试场景 1：验证正常业务操作不受影响
目标：确保 AppArmor 配置不会拦截进程的合法业务行为，避免 “防护过严” 导致业务异常。以 MySQL 为例，执行以下常规操作：
执行核心业务命令
bash
运行
# 1. 登录 MySQL，创建数据库/表/插入数据
mysql -u root -p -e "create database if not exists test_db; use test_db; create table if not exists t1(id int); insert into t1 values(1); select * from t1;"
# 2. 查看数据文件是否正常生成（验证读写权限）
ls -l /var/lib/mysql/test_db/
检查是否有误拦截日志AppArmor 会将拦截行为记录到 /var/log/syslog，执行以下命令排查：
bash
运行
sudo grep -i "apparmor=DENIED.*mysqld" /var/log/syslog
结果判断
配置有效：数据库操作成功，数据文件正常生成，且无 DENIED 日志；
配置过严：操作失败，且日志出现 DENIED 记录 → 需补充被拦截路径的允许规则（如自定义数据目录未添加权限）。
三、 测试场景 2：验证违规越权操作被拦截
目标：模拟攻击者利用进程权限尝试访问敏感资源，验证 AppArmor 能否拦截。MySQL 进程默认以 mysql 用户运行，需切换到该用户执行违规操作，避免 root 权限绕过限制。
子场景 1：测试文件 / 目录访问限制
针对配置中 deny 的敏感目录，尝试读写操作：
bash
运行
# 1. 切换到 mysql 用户（关键：必须用进程运行用户测试）
sudo -u mysql bash
# 2. 尝试写入敏感目录 /root
touch /root/mysql_test.txt
# 3. 尝试读取敏感文件 /etc/shadow
cat /etc/shadow
# 4. 尝试写入/tmp目录（若配置中禁止 /tmp/** rw）
touch /tmp/malicious.sh
# 5. 退出 mysql 用户
exit
子场景 2：测试命令执行限制
若配置中禁止 MySQL 执行 shell 或其他程序，尝试执行：
bash
运行
sudo -u mysql bash
# 尝试执行 /bin/bash
/bin/bash
# 尝试执行系统命令（如 ls）
ls /root
exit
子场景 3：测试网络连接限制
若配置中限制 MySQL 仅允许访问特定 IP / 端口（如仅允许主从同步的 192.168.1.0/24 网段），尝试连接外网卡段：
bash
运行
# 1. 切换到 mysql 用户，安装 nc（若未安装）
sudo -u mysql bash
结果验证：检查拦截日志
执行完所有违规操作后，过滤 AppArmor 日志，确认是否生成 DENIED 记录：
bash
运行
sudo grep -i "apparmor=DENIED.*mysqld" /var/log/syslog
预期有效结果：日志中出现对应违规操作的拦截记录，示例如下：
plaintext
# 拦截写入 /root 的日志
apparmor="DENIED" operation="open" profile="/usr/sbin/mysqld" name="/root/mysql_test.txt" pid=xxxx comm="touch" requested_mask="w" denied_mask="w"
# 拦截执行 /bin/bash 的日志
apparmor="DENIED" operation="exec" profile="/usr/sbin/mysqld" name="/bin/bash" pid=xxxx comm="bash" requested_mask="x" denied_mask="x"
同时，违规操作本身会执行失败（如 /root/mysql_test.txt 未创建、/bin/bash 无法启动）。
四、 测试场景 3：边界测试（验证规则粒度是否精准）
目标：测试配置规则的精准度，避免 “权限范围过宽” 导致防护失效。
测试允许路径的权限粒度若配置中 MySQL 数据目录仅允许 rw（读写），尝试修改文件属性（需 m 权限）：
bash
运行
sudo -u mysql bash
# 尝试修改数据文件属性（若配置无 m 权限，会被拦截）
chmod 777 /var/lib/mysql/test_db/t1.ibd
exit
若配置仅为 /var/lib/mysql/** rw，则 chmod 操作会被拦截，日志出现 DENIED（requested_mask=m）。
测试网络规则的精准度若配置仅允许 MySQL 连接 192.168.1.100:3306，尝试连接同网段的其他 IP：
bash
运行
sudo -u mysql nc -zv 192.168.1.101 3306
若配置精准，连接会被拦截，日志记录 denied_mask=send receive。
五、 测试结果判断与问题修复
测试场景 预期结果 异常情况 修复方案
正常业务 操作成功，无 DENIED 日志 操作失败，有 DENIED 日志 查看日志中 name= 字段，在配置中添加对应路径的允许规则
违规操作 操作失败，有 DENIED 日志 操作成功，无 DENIED 日志 补充对应资源的 deny 规则，或检查配置是否加载
边界测试 超出权限的操作被拦截 超出权限的操作未被拦截 细化规则粒度，避免使用 /** rw 这类宽泛权限
六、 辅助测试工具
实时监控日志测试时实时跟踪拦截日志，便于即时观察结果：
bash
运行
sudo tail -f /var/log/syslog | grep -i "apparmor=DENIED.*mysqld"
批量生成测试用例针对复杂配置，可编写简单脚本批量执行测试操作，例如：
bash
运行
# test_apparmor.sh
#!/bin/bash
sudo -u mysql touch /root/test1.txt
sudo -u mysql cat /etc/shadow
sudo -u mysql /bin/bash
sudo grep -i "apparmor=DENIED.*mysqld" /var/log/syslog
执行脚本后统一查看结果。
七、 注意事项
必须使用进程运行用户测试：若用 root 用户测试，会绕过 AppArmor 限制，导致测试结果无效。
测试后恢复环境：删除测试中创建的临时文件（如 /tmp/malicious.sh），避免残留。
生产环境先切投诉模式验证：若直接在生产环境测试，建议先切换到 complain 模式运行 1-2 天，收集日志确认无业务影响后，再切 enforce 模式。
三二互联专业提供香港VPS,美国VPS主机,香港云服务器租用等业务香港美国到大陆CN2 GIA速度最快
