cups-browsed fails to start in containers after apparmor stacking backport to xenial

Bug #1655982 reported by Stéphane Graber
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

The SRU of apparmor stacking for the Ubuntu 16.04 LTS kernel causes a regression in cups-browsed (shipped by cups) which now fails to start and gets respawned in a loop by systemd until it completely gives up.

To reproduce:
 - lxc launch ubuntu:16.04 xen
 - lxc exec xen -- apt update
 - lxc exec xen -- apt dist-upgrade -y
 - lxc exec xen -- apt install cups -y

You'll get:

root@xen:~# systemctl status cups-browsed
● cups-browsed.service - Make remote CUPS printers available locally
   Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor preset: enabled)
   Active: failed (Result: signal) since Thu 2017-01-12 14:09:38 UTC; 8min ago
 Main PID: 7725 (code=killed, signal=SEGV)

Jan 12 14:09:38 xen systemd[1]: Started Make remote CUPS printers available locally.
Jan 12 14:09:38 xen systemd[1]: cups-browsed.service: Main process exited, code=killed, status=11/SEGV
Jan 12 14:09:38 xen systemd[1]: cups-browsed.service: Unit entered failed state.
Jan 12 14:09:38 xen systemd[1]: cups-browsed.service: Failed with result 'signal'.

And in dmesg (in a loop):
[95217.312576] audit: type=1400 audit(1484230171.171:1004): apparmor="STATUS" operation="profile_load" label="lxd-xen_</var/lib/lxd>//&:lxd-xen_<var-lib-lxd>://unconfined" name="/usr/lib/cups/backend/cups-pdf" pid=16941 comm="apparmor_parser"
[95217.313011] audit: type=1400 audit(1484230171.171:1005): apparmor="STATUS" operation="profile_load" label="lxd-xen_</var/lib/lxd>//&:lxd-xen_<var-lib-lxd>://unconfined" name="/usr/sbin/cupsd" pid=16941 comm="apparmor_parser"
[95217.313202] audit: type=1400 audit(1484230171.171:1006): apparmor="STATUS" operation="profile_load" label="lxd-xen_</var/lib/lxd>//&:lxd-xen_<var-lib-lxd>://unconfined" name="/usr/sbin/cupsd//third_party" pid=16941 comm="apparmor_parser"
[95218.126005] audit: type=1400 audit(1484230171.983:1007): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-xen_<var-lib-lxd>" profile="/usr/sbin/cupsd" name="/run/systemd/journal/stdout" pid=17074 comm="cupsd" requested_mask="w" denied_mask="w" fsuid=100000 ouid=100000
[95218.126018] audit: type=1400 audit(1484230171.983:1008): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-xen_<var-lib-lxd>" profile="/usr/sbin/cupsd" name="/run/systemd/journal/stdout" pid=17074 comm="cupsd" requested_mask="w" denied_mask="w" fsuid=100000 ouid=100000
[95222.686493] audit: type=1400 audit(1484230176.542:1009): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-xen_<var-lib-lxd>" profile="/usr/sbin/cupsd" name="/run/systemd/journal/stdout" pid=17553 comm="cupsd" requested_mask="w" denied_mask="w" fsuid=100000 ouid=100000
[95222.686624] audit: type=1400 audit(1484230176.542:1010): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-xen_<var-lib-lxd>" profile="/usr/sbin/cupsd" name="/run/systemd/journal/stdout" pid=17553 comm="cupsd" requested_mask="w" denied_mask="w" fsuid=100000 ouid=100000
[95224.324494] audit: type=1400 audit(1484230178.182:1011): apparmor="STATUS" operation="profile_load" label="lxd-xen_</var/lib/lxd>//&:lxd-xen_<var-lib-lxd>://unconfined" name="/usr/sbin/cups-browsed" pid=17681 comm="apparmor_parser"
[95224.610016] audit: type=1400 audit(1484230178.466:1012): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-xen_<var-lib-lxd>" profile="/usr/sbin/cups-browsed" name="/run/systemd/journal/stdout" pid=17765 comm="cups-browsed" requested_mask="wr" denied_mask="wr" fsuid=100000 ouid=100000
[95224.610029] audit: type=1400 audit(1484230178.466:1013): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-xen_<var-lib-lxd>" profile="/usr/sbin/cups-browsed" name="/run/systemd/journal/stdout" pid=17765 comm="cups-browsed" requested_mask="wr" denied_mask="wr" fsuid=100000 ouid=100000
[95224.610046] audit: type=1400 audit(1484230178.466:1014): apparmor="DENIED" operation="file_mmap" namespace="root//lxd-xen_<var-lib-lxd>" profile="/usr/sbin/cups-browsed" name="/usr/sbin/cups-browsed" pid=17765 comm="cups-browsed" requested_mask="rm" denied_mask="rm" fsuid=100000 ouid=100000

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

FYI, http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/3658 fixes the /run/systemd/journal/stdout denials. It seems like the real cause of this bug is this denial:

[95224.610046] audit: type=1400 audit(1484230178.466:1014): apparmor="DENIED" operation="file_mmap" namespace="root//lxd-xen_<var-lib-lxd>" profile="/usr/sbin/cups-browsed" name="/usr/sbin/cups-browsed" pid=17765 comm="cups-browsed" requested_mask="rm" denied_mask="rm" fsuid=100000 ouid=100000

Suspecting this had something to do with the flock and mmap mediation fixes, I tried the reproducer with an updated 16.04 kernel (4.4.0-77.98-generic). This fixes the file_mmap denial, but we still have a file_mprotect 'r' denial:

[ 825.339262] audit: type=1400 audit(1493908654.440:86): apparmor="DENIED" operation="file_mprotect" namespace="root//lxd-xen_<var-lib-lxd>" profile="/usr/sbin/cups-browsed" name="/usr/sbin/cups-browsed" pid=14249 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536

I'm not sure if this indicates a bug in the apparmor policy or apparmor itself. If the policy, adjusting /etc/apparmor.d/usr.sbin.cups-browsed to have:

  /usr/sbin/cups-browsed r,

resolves the issue.

Revision history for this message
John Johansen (jjohansen) wrote :

@Jamie may be right in his guesses but there is not enough information here to be sure. The stacking work exists in the Xenial, Yakkety, and Zesty kernels. But the patch Jamie is referring to only exists in the Zesty kernel (it did exist in Xenial and Yakkety until reverted).

Please attach the output of
 uname -a

and
 apparmor_parser -V

for both the host system and the container

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Host:
$ uname -a
Linux sec-xenial-amd64 4.4.0-77-generic #98-Ubuntu SMP Wed Apr 26 08:34:02 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ apparmor_parser -V
AppArmor parser version 2.10.95
Copyright (C) 1999-2008 Novell Inc.
Copyright 2009-2012 Canonical Ltd.

Container:
root@xen:~# uname -a
Linux xen 4.4.0-77-generic #98-Ubuntu SMP Wed Apr 26 08:34:02 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

root@xen:~# apparmor_parser -V
AppArmor parser version 2.10.95
Copyright (C) 1999-2008 Novell Inc.
Copyright 2009-2012 Canonical Ltd.

Note, the reproducer is:

1. apt-get install lxd
2. sg lxd
3. lxc launch ubuntu:16.04 xen
4. lxc exec xen -- apt update
5. lxc exec xen -- apt dist-upgrade -y
6. lxc exec xen -- /bin/bash and edit /etc/apparmor.d/abstractions/base to have:
     /run/systemd/journal/stdout rw,
7. lxc exec xen -- apt install cups -y

and get the denial. If add to /etc/apparmor.d/usr.sbin.cups-browsed in the container:

  /usr/sbin/cups-browsed r,

then I can (after reloading the profile):

$ lxc exec xen -- /bin/bash
root@xen:~# service cups-browsed stop
root@xen:~# service cups-browsed start
root@xen:~# systemctl status cups-browsed
● cups-browsed.service - Make remote CUPS printers available locally
   Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor preset:
   Active: active (running) since Thu 2017-05-04 20:06:50 UTC; 10s ago
 Main PID: 11697 (cups-browsed)
    Tasks: 3
   Memory: 2.5M
      CPU: 17ms
   CGroup: /system.slice/cups-browsed.service
           └─11697 /usr/sbin/cups-browsed

May 04 20:06:50 xen systemd[1]: Started Make remote CUPS printers available locally.

Revision history for this message
John Johansen (jjohansen) wrote :

Okay, this kernel does NOT contain the caching fix. So it is not the cause of the issue.

Revision history for this message
John Johansen (jjohansen) wrote :

So the first kernel tried may have had the flock mediation patch. It was in
  4.4.0-67.88

Reverted in
  4.4.0-70.91

which would help explain the switch in denial from
  file_mmap rm

to
  file_mprotect r

I am unsure why the request for mprotect is showing up. At this point we need to start stracing the application

Emily Ratliff (emilyr)
Changed in apparmor (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for apparmor (Ubuntu) because there has been no activity for 60 days.]

Changed in apparmor (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.