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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1918410
Title:
isc-dhcp-client denied by apparmor
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1918410/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
