SSSD Prevented from Notifying Systemd on Startup by Apparmor

Bug #1689387 reported by Jeffrey Hogan on 2017-05-08
This bug affects 1 person
Affects Status Importance Assigned to Milestone
sssd (Ubuntu)
Andreas Hasenack

Bug Description

Release Details:
Description: Ubuntu 16.04.2 LTS
Release: 16.04

Package version: sssd-common 1.13.4-1ubuntu1.5


Expected: Upon updating sssd-common on 16.04, the sssd service is successfully restarted via:
        systemctl --system daemon-reload >/dev/null || true
        deb-systemd-invoke start sssd.service >/dev/null || true

Observed: The postinst script for sssd-common fails when the systemd service reports a "timeout":
"Job for sssd.service failed because a timeout was exceeded. See "systemctl status sssd.service" and "journalctl -xe" for details."

On 16.04, sssd attempts to notify systemd on startup (via a call to sd_notify). Apparmor prevents this.

Relevant debug log messages from sssd:

(Mon May 8 18:36:29 2017) [sssd] [mark_service_as_started] (0x0400): Sending startup notification to systemd
(Mon May 8 18:36:29 2017) [sssd] [mark_service_as_started] (0x0020): Error sending notification to systemd 13: Permission denied

Corresponding apparmor complaint entries:

kernel: [425822.018708] audit: type=1400 audit(1494268589.535:226): apparmor="DENIED" operation="sendmsg" profile="/usr/sbin/sssd" name="/run/systemd/notify" pid=22917 comm="sssd" requested_mask="w" denied_mask="w" fsuid=0 0

Adding the following entry to the loaded apparmor profiles sees the issue resolved:

/{,var/}run/systemd/notify w,

This may ultimately be an issue with the packaged apparmor profiles for 16.04, but we first saw it manifest upon upgrading sssd-common to 1.13.4-1ubuntu1.5

Jeffrey Hogan (jeff-hogan1) wrote :

The sd_notify call that shows up in this diff may be implicated:

Robie Basak (racb) on 2017-05-22
tags: added: bitesize server-next
Changed in sssd (Ubuntu):
status: New → Triaged
importance: Undecided → High
Andreas Hasenack (ahasenack) wrote :

Did you change the apparmor profile to be in enforcing mode? By default it's in complain mode as far as I can see:

lrwxrwxrwx 1 root root 16 Jun 19 20:48 /etc/apparmor.d/force-complain/usr.sbin.sssd -> ../usr.sbin.sssd

That being said, I can see at least one more missing rule, this time for the chown capability:
[ 1690.540498] audit: type=1400 audit(1497905549.525:43): apparmor="ALLOWED" operation="capable" profile="/usr/sbin/sssd" pid=9946 comm="sssd" capability=0 capname="chown"

Changed in sssd (Ubuntu):
assignee: nobody → Andreas Hasenack (ahasenack)
Changed in sssd (Ubuntu):
status: Triaged → In Progress
Jeffrey Hogan (jeff-hogan1) wrote :

Hi Andreas:

Yes, for our use case we explicitly set the sssd profile to enforce mode. E.g., `aa-enforce /usr/sbin/sssd`.

Andreas Hasenack (ahasenack) wrote :

Ok, that explains it. I'll update the profile with what you found and the other missing pieces, which I suppose you also had to add.

Andreas Hasenack (ahasenack) wrote :

I filed bug #1699576 for the missing chown capability

Andreas Hasenack (ahasenack) wrote :

I'll change this bug to "low" because to be affected one has to change the profile from complain (the default) to enforce.

Changed in sssd (Ubuntu):
importance: High → Low
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package sssd - 1.15.2-1ubuntu2

sssd (1.15.2-1ubuntu2) artful; urgency=medium

  * d/apparmor-profile:
    - allow the chown capability (LP: #1699576)
    - allow sssd to notify systemd during startup (LP: #1689387)

 -- Andreas Hasenack <email address hidden> Wed, 21 Jun 2017 15:50:35 -0300

Changed in sssd (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers