5

I successfully upgraded my KVM server to 20.04.1 LTS but when later trying to access it by ssh, there were no network route to the server, while the VMs still were happily running just great. Logging in to the console, I discovered the bridge had lost its IPv4 address and dhclient was not running any longer. This happens repeatedly, the bridge receives its IPv4 at boot, but seems to lose it after the first lease. After having issued dhclient -r br0 I found this in the logs:

audit: type=1400 audit(1611698389.262:14): apparmor="DENIED" operation="open" profile="/{,usr/}sbin/dhclient" name="/proc/1878/task/1881/comm" pid=1878 comm="dhclient" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

I was able to fix this by adding /proc/*/task/*/comm wr, to /etc/apparmor.d/local/sbin.dhclient. But, why in the first place, does dhclient need wr access to /proc...? My backup server, also on 20.04.1 LTS, runs fine without this.

lnappa
  • 151

2 Answers2

5

There is a bug reported for this: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1918410 and fix in AppArmor https://gitlab.com/apparmor/apparmor/-/merge_requests/730 with a good string:

owner @{PROC}/@{pid}/task/[0-9]*/comm rw,

To fix this, edit the /etc/apparmor.d/sbin.dhclient file with a text editor and add the above line to it.

Error404
  • 8,278
  • 3
  • 35
  • 60
3

AppArmor is NOT killing dhclient, it is only denying access to the file /proc/1878/task/1881/comm, and logging that the violation happened. If AppArmor had killed dhclient the message would have had apparmor="KILLED" instead of apparmor="DENIED".

If dhclient is exiting after the denial it would be because it is handling the denial as a fatal error.

As to why dhclient is asking for access to that file, it appears to be wanting to change the comm of some of its threads. You can find more info on that file with man 5 proc.

Adding the suggested rule should generally be safe.

sotirov
  • 4,379