解决ubuntu环境下报apparmor=“DENIED“ operation=“exec“之类的错误

apparmor的权限规则一般默认放在/etc/apparmor.d/目录下,比如tcpdump的规则存放在该目录下的usr.sbin.tcpdump下,其内容有固定的格式,它相当于白名单,规定了该应用对于目录的访问权限。应用要想访问某个目录,则必须在这个文件里加上权限,否则就会报错,比如使用下面的命令:

# 重启某个服务,这里以docker为例
systemctl restart snap.docker.dockerd
# 查看日志
journalctl -xe

如果权限不足,会查到报错信息如下:

Mar 04 14:43:17 ubuntu audit[5657]: AVC apparmor="DENIED" operation="ptrace" profile="snap.docker.dockerd" pid=5657 comm="ps" requested_mask="trace" denied_mask="trace" peer="/sbin/dhclient"

这个时候你就需要修改snap.docker.dockerd,但这里要注意这个文件不是放在/etc/apparmor.d/目录里的,因为对于snap安装的应用,它们的配置会放到/var/lib/snapd/apparmor/profiles/目录里,它的格式是下面这样的(以tcpdump为例):

# vim:syntax=apparmor
# Last Modified: Wed Feb  3 07:58:30 2009
# Author: Jamie Strandboge <jamie@canonical.com>
#include <tunables/global>

/usr/sbin/tcpdump {
  #include <abstractions/base>
  #include <abstractions/nameservice>
  #include <abstractions/user-tmp>

  capability net_raw,
  capability setuid,
  capability setgid,
  capability dac_override,
  network raw,
  network packet,

  # for -D
  capability sys_module,
  @{PROC}/bus/usb/ r,
  @{PROC}/bus/usb/** r,

  # for finding an interface
  @{PROC}/[0-9]*/net/dev r,
  /sys/bus/usb/devices/ r,
  /sys/class/net/ r,
  /sys/devices/**/net/* r,

  # for -j
  capability net_admin,

  # for tracing USB bus, which libpcap supports
  /dev/usbmon* r,
  /dev/bus/usb/ r,
  /dev/bus/usb/** r,

  # for init_etherarray(), with -e
  /etc/ethers r,

  # for USB probing (see libpcap-1.1.x/pcap-usb-linux.c:probe_devices())
  /dev/bus/usb/**/[0-9]* w,

  # for -z
  /{usr/,}bin/gzip ixr,
  /{usr/,}bin/bzip2 ixr,

  # for -F and -w
  audit deny @{HOME}/.* mrwkl,
  audit deny @{HOME}/.*/ rw,
  audit deny @{HOME}/.*/** mrwkl,
  audit deny @{HOME}/bin/ rw,
  audit deny @{HOME}/bin/** mrwkl,
  owner @{HOME}/ r,
  owner @{HOME}/** rw,

  # for -r, -F and -w
  /**.[pP][cC][aA][pP] rw,

  # for convenience with -r (ie, read pcap files from other sources)
  /var/log/snort/*log* r,

  /usr/sbin/tcpdump mr,

  # Site-specific additions and overrides. See local/README for details.
  #include <local/usr.sbin.tcpdump>
}

如果你嫌配置这个文件麻烦,有一个较为简单省事的方法可以替代。apparmor分成两种模式,一种模式是enforce mode,一种模式是complain mode。前者会严格按照配置规则来控制应用的访问权限,后者不会禁止应用访问文件,但会记录下来。使用命令:

apparmor_status

可以看到每个应用处在什么模式下,比如我的电脑配置如下:

root@ubuntu:~# apparmor_status
apparmor module is loaded.
28 profiles are loaded.
28 profiles are in enforce mode.
   /sbin/dhclient
   /snap/core/10823/usr/lib/snapd/snap-confine
   /snap/core/10823/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /snap/core/10859/usr/lib/snapd/snap-confine
   /snap/core/10859/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/bin/lxc-start
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/lxd/lxd-bridge-proxy
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/sbin/tcpdump
   docker-default
   lxc-container-default
   lxc-container-default-cgns
   lxc-container-default-with-mounting
   lxc-container-default-with-nesting
   snap-update-ns.core
   snap-update-ns.docker
   snap.core.hook.configure
   snap.docker.compose
   snap.docker.docker
   snap.docker.dockerd
   snap.docker.help
   snap.docker.hook.install
   snap.docker.hook.post-refresh
   snap.docker.machine
0 profiles are in complain mode.
3 processes have profiles defined.
3 processes are in enforce mode.
   /sbin/dhclient (1069)
   snap.docker.dockerd (5543)
   snap.docker.dockerd (5618)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

可以看到snap.docker.dockerd是enforce mode。只需要把它改为complain mode,则就会省去一个个配置的麻烦。使用aa-complain命令可以进行修改,在使用这个命令之前,你需要安装一个工具,如下:

 apt install apparmor-utils

安装好之后,使用下面的命令进行变更:

sudo aa-complain /var/lib/snapd/apparmor/profiles/snap.docker.dockerd

但这里会报错:

Profile for /var/lib/snapd/apparmor/profiles/snap.docker.dockerd not found, skipping

这里感觉像是一个bug。我刚才说了,snap安装的应用配置文件都是放到/var/lib/snapd/apparmor/profiles/目录下,而普通的应用的配置会放到/etc/apparmor.d/目录下,放到/etc/apparmor.d/目录下的会被识别,但是其他的目录的不会被识别,比如同样的一个配置,如果放到/etc/apparmor.d/目录下,则不会报上面的错,把snap.docker.dockerd拷贝到/etc/apparmor.d/目录,然后执行:

sudo aa-complain /etc/apparmor.d/snap.docker.dockerd

结果如下:

执行结束之后,把两个文件打开,比对一下区别。

原来的:

新的:

可以看到新增了一个complain。然后再把/etc/apparmor.d/目录下被修改过的配置文件拷贝到/var/lib/snapd/apparmor/profiles/替换掉原来的,那么这个配置文件就修改成功了。这里我把/var/lib/snapd/apparmor/profiles/目录下的所有配置全部都给修改掉了。使用:

sudo aa-complain /etc/apparmor.d/snap*

可以批量修改所有snap开头的配置。修改之后重启电脑,再使用apparmor_status命令查看,结果如下:

root@ubuntu:~# apparmor_status
apparmor module is loaded.
26 profiles are loaded.
14 profiles are in enforce mode.
   /sbin/dhclient
   /usr/bin/lxc-start
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/lxd/lxd-bridge-proxy
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/sbin/tcpdump
   docker-default
   lxc-container-default
   lxc-container-default-cgns
   lxc-container-default-with-mounting
   lxc-container-default-with-nesting
12 profiles are in complain mode.
   /snap/core/10859/usr/lib/snapd/snap-confine
   /snap/core/10859/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   snap-update-ns.core
   snap-update-ns.docker
   snap.core.hook.configure
   snap.docker.compose
   snap.docker.docker
   snap.docker.dockerd
   snap.docker.help
   snap.docker.hook.install
   snap.docker.hook.post-refresh
   snap.docker.machine
3 processes have profiles defined.
1 processes are in enforce mode.
   /sbin/dhclient (1133)
2 processes are in complain mode.
   snap.docker.dockerd (1218)
   snap.docker.dockerd (1370)
0 processes are unconfined but have a profile defined.

可以看到已经被改掉了,这个时候,再通过snap去启动docker,就没有apparmor相关的报错了。

<think>嗯,用户想了解如何查看AppArmor的成功和失败日志。首先,我需要回忆一下AppArmor的基本知识。AppArmor是一个Linux内核的安全模块,用于限制程序的功能。它通过配置文件来定义应用程序的访问权限,比如文件、网络等。当应用程序违反这些规则时,AppArmor会记录日志,这对系统管理员来说非常重要,可以用来排查问题或调整策略。 用户之前询问过关于用Python脚本测试D-Bus消息发送的问题,现在转向AppArmor日志,可能是在进行系统安全相关的开发或维护,比如调试某个被AppArmor限制的应用。需要确定用户的使用场景,可能是他们遇到了某些权限被拒绝的问题,需要查看日志来确认是否是AppArmor引起的。 接下来,我需要整理查看AppArmor日志的方法。通常,这些日志会记录在系统日志中,比如/var/log/syslog或/var/log/auth.log,具体取决于发行版的配置。可能需要使用grep命令过滤出AppArmor相关的条目,比如使用“apparmor”或“DENIED”作为关键字。另外,dmesg命令也可以查看内核日志,可能会有AppArmor的拒绝信息。 另外,用户可能需要区分成功和失败的日志。失败日志通常包含“DENIED”或“audit”关键字,而成功加载配置的信息可能用“ALLOWED”或“loaded”等。需要具体说明如何识别这些信息。 还要考虑不同Linux发行版的差异,比如Ubuntu和CentOS的日志位置可能不同,可能需要提示用户根据实际情况调整路径。此外,AppArmor的状态管理命令,如apparmor_status,也可能对用户有帮助,可以检查哪些配置文件处于执行模式。 用户可能还需要知道如何实时监控日志,比如使用tail -f命令,或者如何调整日志的详细程度,比如通过auditd配置。如果有时间的话,可以给出一些实际例子,比如查看某个特定应用的日志,或者如何解决常见的权限问题。 需要注意的是,用户可能对命令行操作不太熟悉,所以步骤需要详细,命令要准确。同时,可能还要提醒用户权限问题,比如查看日志可能需要sudo权限。 最后,要确保回答结构清晰,分步骤说明,可能包括日志位置、查看方法、过滤关键字、示例输出、常见问题解决等部分。如果有相关的进阶技巧,比如使用工具解析日志或调整AppArmor配置文件,也可以简要提及。</think>--- ### **AppArmor 日志查看指南** AppArmor 是 Linux 内核的安全模块,用于限制应用程序的权限。其日志记录了策略加载、权限拒绝等关键事件。以下是查看成功与失败日志的详细方法: --- #### **1. 日志文件位置** AppArmor 日志通过内核审计系统(`auditd`)或系统日志(`syslog`)记录,具体路径取决于系统配置: | 日志类型 | 路径 | 适用场景 | |----------------|---------------------------------|------------------------------| | **系统日志** | `/var/log/syslog` | Ubuntu/Debian 默认日志 | | | `/var/log/messages` | CentOS/RHEL 默认日志 | | **审计日志** | `/var/log/audit/audit.log` | 启用 `auditd` 服务的系统 | --- #### **2. 查看失败日志(权限拒绝)** 失败日志通常包含 `DENIED` 或 `audit` 关键字,反映应用程序违反策略的操作。 **命令示例**: ```bash # 查看 syslog 中的拒绝记录 sudo grep "apparmor.*DENIED" /var/log/syslog # 查看 audit.log 中的拒绝记录 sudo grep "apparmor.*DENIED" /var/log/audit/audit.log # 使用 dmesg 直接查看内核日志 dmesg | grep apparmor | grep denied ``` **输出示例**: ``` apparmor="DENIED" operation="open" profile="/usr/sbin/nginx" name="/etc/secret.txt" pid=1234 comm="nginx" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 ``` - **关键字段解释**: - `profile`:触发的 AppArmor 策略名称(如 `/usr/sbin/nginx`)。 - `operation`:被拒绝的操作类型(如 `open`, `exec`, `network`)。 - `name`:被访问的资源路径(如 `/etc/secret.txt`)。 - `denied_mask`:拒绝的权限(如 `r` 表示读权限)。 --- #### **3. 查看成功日志(策略加载/允许)** 成功日志包含策略加载或权限允许事件,关键字为 `ALLOWED` 或 `loaded`。 **命令示例**: ```bash # 查看已加载的策略 sudo apparmor_status # 查看策略加载日志 sudo grep "apparmor.*loaded" /var/log/syslog # 查看允许的操作(需策略开启日志) sudo grep "apparmor.*ALLOWED" /var/log/syslog ``` **输出示例**: ``` apparmor="STATUS" operation="profile_load" name="/usr/sbin/nginx" pid=5678 comm="apparmor_parser" ``` - **关键字段解释**: - `profile_load`:表示策略文件已成功加载。 - `name`:加载的策略名称(如 `/usr/sbin/nginx`)。 --- #### **4. 实时监控日志** 动态跟踪 AppArmor 事件: ```bash # 监控 syslog(Ubuntu/Debian) sudo tail -f /var/log/syslog | grep apparmor # 监控 audit.log(CentOS/RHEL) sudo tail -f /var/log/audit/audit.log | grep apparmor ``` --- #### **5. 常见问题排查** | 问题现象 | 解决方案 | |--------------------------|--------------------------------------------------------------------------| | **日志无输出** | 确认 AppArmor 是否启用:`sudo systemctl status apparmor` | | | 检查策略是否设置为 `enforce` 模式:`sudo aa-enforce /path/to/profile` | | **权限拒绝但无日志** | 确保策略未配置 `deny` 静默规则,或检查 `auditd` 服务是否运行正常 | | **日志量过大** | 调整策略的日志级别:在配置文件中添加 `audit` 或 `quiet` 关键字 | --- #### **6. 进阶调试** - **自定义日志规则**: 在 AppArmor 策略文件中指定日志行为: ```bash # 记录所有拒绝事件(即使策略默认允许) audit /etc/secret.txt r, # 仅记录特定操作的允许 /var/log/nginx/* w log, ``` - **解析审计日志**: 使用 `ausearch` 工具解析审计事件: ```bash sudo ausearch -m avc -ts recent | grep apparmor ``` --- ### **总结** 通过上述方法,您可以快速定位 AppArmor 的权限问题: 1. **失败日志** → 修复策略或调整应用程序行为。 2. **成功日志** → 验证策略是否按预期加载。 3. **实时监控** → 动态调试敏感操作。 若需调整策略,请参考日志中的 `name` 和 `denied_mask` 字段修改配置文件(通常位于 `/etc/apparmor.d/`)。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值