AppArmor可限制MariaDB的文件访问、网络行为和系统能力，但不能替代其自身用户权限体系；需确保策略存在、处于enforce模式，并与数据库GRANT权限协同使用。
AppArmor 可以有效限制数据库服务（如 MariaDB/MySQL）的文件访问、网络行为和系统能力，但不能替代数据库自身的用户权限体系。它起作用的前提是：服务进程由 AppArmor 策略文件明确覆盖，且策略处于 enforce 模式。
数据库服务必须被 AppArmor 显式保护
Ubuntu/Debian 默认不为所有数据库服务启用 AppArmor 策略。MariaDB 官方包可能自带基础配置（如 /etc/apparmor.d/usr.sbin.mysqld），但 MySQL 社区版通常没有。你需要确认策略是否存在：
- 运行
sudo aa-status | grep mysqld或sudo aa-status | grep mariadb，看是否列出已加载的配置 - 检查
/etc/apparmor.d/下有无对应文件，例如usr.sbin.mysqld、usr.sbin.mariadbd - 若不存在，需手动创建或从
apparmor-profiles-extra包安装（sudo apt install apparmor-profiles-extra）
关键权限控制项（以 MariaDB 为例）
一个实用的策略应聚焦三类最小化约束：
-
文件路径白名单：只允许访问必要目录，例如
/var/lib/mysql/** rwk,/etc/mysql/** r,/var/log/mysql/** rw,/run/mysqld/mysqld.sock w,
拒绝通配符写入（如/tmp/**或/root/**） -
网络绑定限制：配合配置文件中的
bind-address使用
若 MariaDB 设置为bind-address = 127.0.0.1，AppArmor 可添加：network inet stream,（允许本地 TCP）
但显式禁止：network inet6 stream,（除非真需要 IPv6）network netlink raw,（避免滥用路由信息） -
能力（capability）裁剪：默认策略常保留过多能力
移除非必需项，例如：capability dac_override,（绕过文件权限）capability sys_admin,（挂载/卸载文件系统）
保留必要项如capability setgid, setuid,（切换到 mysql 用户）
验证与调试流程
策略上线前务必测试，避免服务启动失败：
- 先用投诉模式加载：
sudo apparmor_parser -r -C /etc/apparmor.d/usr.sbin.mariadbd - 重启 MariaDB：
sudo systemctl restart mariadb - 查看拒绝日志：
sudo dmesg | grep -i avc | tail -20或检查/var/log/audit/audit.log（若 auditd 启用） - 根据日志补全缺失规则（如缺少对
/proc/sys/kernel/osrelease的读取），再重新加载为 enforce 模式：sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.mariadbd
与数据库自身权限协同使用
AppArmor 控制的是“操作系统层”的行为，而 GRANT 语句控制的是“数据库逻辑层”的操作。两者必须配合：
- AppArmor 允许 MariaDB 进程读写
/var/lib/mysql/myapp/目录 → 但不等于允许数据库用户myapp_user执行DROP TABLE - 仍需在 SQL 中执行：
GRANT SELECT, INSERT ON myapp.* TO 'myapp_user'@'localhost'; - 敏感配置文件（如
/etc/mysql/my.cnf）应设为600并属主mysql:mysql，AppArmor 策略中仅声明r权限即可
