isc-dhcp-client denied by apparmor

Bug #1918410 reported by Anisse Astier on 2021-03-10
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
isc-dhcp (Ubuntu)
Medium
Unassigned

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)

Anisse Astier (anisse) wrote :

I forgot to add that this is an up-to-date Ubuntu 20.04.2

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in isc-dhcp (Ubuntu):
status: New → Confirmed
Sean Ford (sford) wrote :

I have been doing Xenial -> Bionic -> Focal release upgrades and started running into this apparmor issue with dhclient after reaching Focal.

I don't know the root issue, and it doesn't appear to impact functionality (at least as far as I can tell on my hosts). However, I am currently dealing with this by adding the following to /etc/apparmor.d/local/sbin.dhclient:

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

John Johansen (jjohansen) wrote :

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.

John Johansen (jjohansen) wrote :

Okay adding the suggested rule

works for me. So it would seem dhclient is treating denied access to comm as a fatal error.

Interestingly I also had it throw a rejection for capability sys_module

[ 1645.480546] audit: type=1400 audit(1616847221.859:73): apparmor="DENIED" operation="capable" profile="/{,usr/}sbin/dhclient" pid=3380 comm="dhclient" capability=16 capname="sys_module"

which should not generally be required anymore. See https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1759032

John Johansen (jjohansen) wrote :

To further elaborate on why dhclient is accessing the comm

$ pstree -at 3395
dhclient ens3
  ├─{isc-socket}
  ├─{isc-timer}
  └─{isc-worker0000}

where 3395 is the process. It has 3 additional threads and it is providing functional names for them.

Sean Ford (sford) wrote :

Hi John,

Thank you for your detailed response and education on command text. I was able to use pstree to see the thread command text behavior change before and after the AppArmor rule addition. I feel better now that I understand what is going on!

John Johansen (jjohansen) wrote :

Merge upstream https://gitlab.com/apparmor/apparmor/-/merge_requests/730

it will be part of the next apparmor point releases

tags: added: focal
Changed in isc-dhcp (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers