unbound-control local socket broken by apparmor

I disagree with this. While both bugs are related to app armor, they are not related in any way.

#1723900 is about permission to write in systemd/notify socket, while this one is about using a local socket for unbound-control.

@Jean-Daniel, sorry, I hastily duped it (now undone). Could you share your config as well as the apparmor denials. FYI, the Apparmor profile authorizes the creation of a control socket in /run/unbound.ctl:

  # Unix control socket
  /{,var/}run/unbound.ctl rw,

My config is:

remote-control:
 control-enable: yes
 control-interface: /var/run/unbound.ctl

The socket created, but then, unbound can't properly change the owner to unbound:unbound.

Feb 21 13:08:21 linux-agent systemd[1]: Starting Unbound DNS server...
Feb 21 13:08:22 linux-agent unbound[6486]: [1519214902] unbound[6486:0] error: cannot chown 114.125 /var/run/unbound.ctl: Operation not permitted

If the apparmor profile is changed to allow chown, it raise a second issue which is that unbound can't properly set permissions on the socket:

Feb 21 13:10:37 linux-agent audit[6788]: AVC apparmor="DENIED" operation="capable" profile="/usr/sbin/unbound" pid=6788 comm="unbound" capability=3 capname="fowner"

I was trying to follow your case, but hit even more:

[2794286.784575] apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/unbound" name="/run/systemd/notify" pid=4938 comm="unbound" requested_mask="w" denied_mask="w" fsuid=118 ouid=0
[2794367.925181] apparmor="DENIED" operation="open" profile="/usr/sbin/unbound" name="/var/lib/sss/mc/initgroups" pid=5111 comm="unbound" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

That would need:
  /run/systemd/notify w,
  /var/lib/sss/mc/initgroups r,

With that in place I added /etc/unbound/unbound.conf.d/rc.conf as in the report above.
I didn't trigger the mentioned denies, but then maybe one would have to setup unbound a bit more to do so.
If you can share the steps needed to trigger in addition to said config file.

Also if anyone does an upload later I think fixing the two extra rules I outlined should be grouped with the fix.

On 2018-02-23 09:40 AM, ChristianEhrhardt wrote:
> That would need:
> /run/systemd/notify w,

The notify problem was taken care of in LP: #1723900 :)

> /var/lib/sss/mc/initgroups r,

IMHO, this should be in abstractions/nameservice which is already
included in the Unbound profile. Christian, would you mind opening a bug
about it? I don't have any sssd setup here. Thanks

Regards,
Simon

@Christian

Adding the rc.conf file should be enough but unless you add

/run/systemd/notify w,

unbound won't get far enough to trigger the chown issue.

----
For the second issue, change the 'deny capability chown,' to 'capability chown,' in the unbound apparmor profile, restart apparmor and restart unbound. It should log the fowner error.

Unfortunately, I'm not sure what side effect changing that line will have. Simon can probably tell us more as he is the one who adds it in the first place:

https://bazaar.launchpad.net/~sdeziel/apparmor-profiles/unbound-chown/revision/169

Oh it is a silent deny
  deny capability chown,
Yes I see now.

Ok so overall:

  deny capability chown -> capability chown
  (can we limit that to a certain scope)

> /run/systemd/notify w,

The notify problem was taken care of in LP: #1723900 :)

I have hit that in Bionic just now....

>> /var/lib/sss/mc/initgroups r,

>IMHO, this should be in abstractions/nameservice which is already
>included in the Unbound profile. Christian, would you mind opening a bug
>about it? I don't have any sssd setup here. Thanks

I have no sssd either, that is just a bionic container.

Before spreading that out to more bugs I'll subscribe jdstrand here.
Maybe he can spot an overall pattern (e.g. on my bionic container) so that this could be "just" the discussion on the capability.
Also I'd like to have his opinion on opening up chown cap for this.

"Ok so overall:

  deny capability chown -> capability chown
  (can we limit that to a certain scope)"

Unfortunately, no, not unless we get help from unbound to change_profile/change_onexec after a fork/exec or it is happening in a helper binary that we could separately profile.

"deny capability chown" was initially added for the PID file, see [1]. Failing to chown the PID or the control socket is only logged at higher log level specifically to not generate noise when the chown capability isn't available, see [2,3]. The "capability fowner" was removed based on [4].

Currently, the unbound control socket is only accessible to root requiring one to use "sudo unbound-control" (aka the bug at hand):

  $ ll /run/unbound.ctl
  srw-rw---- 1 root root 0 Feb 23 18:40 /run/unbound.ctl=

Re-introducing the chown/fowner caps would give us:

  $ ll /run/unbound.ctl
  srw-rw---- 1 unbound unbound 0 Feb 23 18:38 /run/unbound.ctl=

which would fix the bug at the expense of those additional caps.

I'd vote in favor of re-introducing the capability for the sake of not having Apparmor "getting in the way". If that's OK with everyone, I'd send the patch to Debian as well.

1: https://code.launchpad.net/~sdeziel/apparmor-profiles/unbound-refresh/+merge/282230
2: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=734
3: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1332
4: https://lists.ubuntu.com/archives/apparmor/2016-January/009278.html

Hi Simon,
my personal stance to apparmor is to lock as much as possible without breaking the common use cases. And uncommon use cases should be able to e.g. use local overrides to work.

In this case I think (my opinion isn't worth a lot on this thou) you are right and we should re-introduce the cap.
For now that seems to be the more functional approach.

Thanks for your volunteering to drive to Debian as well.

OTOH for Ubuntu we might need an own upload.
As bug 1749931 (our only current Delta to Debian) is also still waiting.

@Sdezial: If you don't mind - please propose something to Debian but also create a Debdiff for Ubuntu that we can sponsor into 18.04.
That way 18.04 will be good, and Debian will pick it up at some point as well allowing us to drop the Delta.

+1 to add 'capability chown' to the profile, and also for '/var/lib/sss/mc/initgroups r,' (since it may or may not make it into apparmor SRU in a timely manner.

On 2018-02-26 01:58 PM, Jamie Strandboge wrote:
> +1 to add 'capability chown' to the profile, and also for
> '/var/lib/sss/mc/initgroups r,' (since it may or may not make it into
> apparmor SRU in a timely manner.

OK, I'll do that but just to be clear, 'capability fowner' is also
needed and I'll incorporate it as well.

I did further tests with a Bionic container on a Xenial host. There, I also needed to add "capability fsetid".

Here's a debdiff for Bionic.

The attachment "18.04-lp1749931.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

Debdiff is good, thanks Simon!.
I think it is fair to add fsetid for now to work.
If details are found how that can be limited later we can do so still.

With the fixes applied as expected the control socket is usable now when running from [1] in a container.

(my old) lintian complains about a few things, but none of it were touched on this change - so leaving them as is for now.

Sponsoring into bionic [2]

Please help tracking the migration over the next few days ...

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3178/+packages
[2]: https://launchpad.net/ubuntu/+source/unbound/1.6.7-1ubuntu2

Thanks Christian!

FYI - Tests are all good (in proposed migration) it just has to wait for the newer glibc it was build against to pass (this will bring a lot more in as there is a wake behind glibc building up atm).

This bug was fixed in the package unbound - 1.6.7-1ubuntu2

---------------
unbound (1.6.7-1ubuntu2) bionic; urgency=medium

  * debian/apparmor-profile: add capabilities to chown/chmod Unix
    control socket and allow reading /var/lib/sss/mc/initgroups
    (Closes: #891705, LP: #1749931)

 -- Simon Deziel <email address hidden> Tue, 27 Feb 2018 21:31:49 -0500