正在对’拆卸’不安全的AppArmor进行故障排除？
我了解有一种更安全，更有针对性的方法来解决AppArmor对问题的可能贡献，而不是完全停止服务并拆除AppArmor配置文件。 有人可以给我详细介绍，以及更好的方法的优点吗？
这就是我的想法（来自https://wiki.ubuntu.com/DebuggingApparmor ） – “抱怨模式”。 这并未解决与其他调试方法相比的相对优点或后果的问题。
调试时，将apparmor置于“抱怨”模式也可能很有用。 这将允许您的应用程序正常运行，而apparmor报告不在配置文件中的访问。 要启用“抱怨”模式，请使用：
sudo aa-complain /path/to/bin其中’/ path / to / bin’是二进制文件的绝对路径，如’audit’条目的’profile = …’部分所报告的那样。 例如：
sudo aa-complain /usr/sbin/slapd要重新启用强制执行模式，请改为使用“aa-enforce”：
sudo aa-enforce /path/to/bin要禁用配置文件：
sudo touch /etc/apparmor.d/disable/path.to.bin sudo apparmor_parser -R /etc/apparmor.d/path.to.bin
然后在进行故障排除时，如果有一些损坏似乎与一个怪异的权限问题有关（’嗯，看起来像访问控制，但它不是Unix权限问题，或NFS问题，或PAM问题，或媒体安装傻瓜等等 – 也许是它的AppArmor。’），Kees Cook指出最好的行动方案是检查你的系统日志。 值得注意的是，根据Kees Cook的说法，“ dmesg的输出将报告所有AppArmor否认，并将包含该配置文件。”