Denying /proc/1095210/task/1095213/comm prevents the task from introspecting (reading), and changing (write) the command text associated with the task. In this case it would appear one thread is attempting to change the comm of another thread in the process (this is generally allowed), see man 5 proc
Reading isn't considered a problem, writing is more interesting. A process may use it to provide more info, like this is a sandbox thread, renderer etc. But a compromised task could also use it to masquerade its comm as another task. It won't hide the task but could make it harder to kill or monitor if the user is looking for the default comm value. Denying this is not directly related to lack of IPv4 (kernel wise it has no relation), but application behavior could be such that when it fails to access the comm field it handles the error poorly resulting in it failing to setup IPv4. I would recommend a modification to the above rule, changing [0-9]* to @{pids} @{PROC}/@{pids}/task/[0-9]*/comm rw, Does adding the above rule fix the IPv4 issue for you? From comment #3 I assume no, but maybe I am reading it wrong. Are there any other denials in your logs? As for disabling AppArmor for dhclient? It is precisely the the type of service (network facing root service) I would not recommend disabling the apparmor profile for. Instead updating the profile is the way to go. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1918410 Title: isc-dhcp-client denied by apparmor Status in isc-dhcp package in Ubuntu: Confirmed Bug description: Hi, I get weird errors in the audit log, seeing dhclient is being denied reading its comm or the comm of one of its tasks: [1383307.827378] audit: type=1400 audit(1615367094.054:162): apparmor="DENIED" operation="open" profile="/{,usr/}sbin/dhclient" name="/proc/1095210/task/1095213/comm" pid=1095210 comm="dhclient" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0 This might or might not be linked with the fact that I can't get an IPv4 on this interface. Note that it happened to other, see this comment: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1413232/comments/8 Or even an article recommending disabling apparmor for dhclient(!): https://blog.anthony-jacob.com/perte-dip-v4-sous-ubuntu-20-04-apparmor-et-dhclient/ As I said, I'm not sure this is the root cause of the lack of IPv4 renewal, because running it manually *does* succeed in getting an IP. And running it in strace shows the EACCES failure: [pid 1095210] openat(AT_FDCWD, "/proc/self/task/1095211/comm", O_RDWRstrace: Process 1095211 attached ) = -1 EACCES (Permission non accordée) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1918410/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp