CUPS + SSSD: cannot access local CUPS web interface with domain user (apparmor problem)

[Robert Euhus]

[Summary]
My domain user can not access the local CUPS web interface due to apparmor denials.

Adding the following two lines to /etc/apparmor.d/local/usr.sbin.cupsd fixes it:

/var/lib/sss/pipes/private/pam rw,
unix (bind) type=dgram addr=@userdb-*,

[Details]
I have a (relatively) clean install of Ubuntu 20.04 (no upgrade), which is joined to a Windows AD-domain via sssd, but currently used off site with cached credentials.

When I try to log in with my domain user (who is in the lpadmingroup) at the local cups web interface (localhost:631 ...> Add Printer) with the default apparmor config for cupsd I get a:
AVC apparmor="DENIED" operation="connect" profile="/usr/sbin/cupsd" name="/var/lib/sss/pipes/private/pam" pid=189759 comm="cupsd" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

This already existed in Bionic and my workaround was to add '/var/lib/sss/pipes/private/pam rw,' to /etc/apparmor.d/local/usr.sbin.cupsd and reload the profile:
# echo '/var/lib/sss/pipes/private/pam rw,' > /etc/apparmor.d/local/usr.sbin.cupsd
# apparmor_parser -r -W -T /etc/apparmor.d/usr.sbin.cupsd

This worked in Bionic, but leads to a crash of cupsd in Focal when I try to log in as domain user with a the following log message nearby:
AVC apparmor="DENIED" operation="bind" profile="/usr/sbin/cupsd" pid=189759 comm="cupsd" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-7625b1ef65396344ef05f0a8aeda870e"

This looks very similar to https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1890858 , so I applied the same fix and added 'unix (bind) type=dgram addr=@userdb-*,' to /etc/apparmor.d/local/usr.sbin.cupsd:
# echo 'unix (bind) type=dgram addr=@userdb-*,' >> /etc/apparmor.d/local/usr.sbin.cupsd
# apparmor_parser -r -W -T /etc/apparmor.d/usr.sbin.cupsd

Which fixed my problem.

I am not an expert on apparmor, so I have no idea, if the first line gives too broad permissions.

I think that there are two unrelated issues:
1) Cupsd cannot access sssd at all. This already existed in Bionic (but I failed to report the issue -- sorry for that).
2) Once the login succeeds, cups tries to resolve a uid/gid as it isn't known locally. To resolve it it needs to bind a unix socket. See: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1890858/comments/37

I will attach a full log with added comments on what I did.

[Infos]
1) lsb_release -rd
Description: Ubuntu 20.04.2 LTS
Release: 20.04

2) apt-cache policy cups-daemon
cups-daemon:
  Installiert: 2.3.1-9ubuntu1.1
  Installationskandidat: 2.3.1-9ubuntu1.1
  Versionstabelle:
 *** 2.3.1-9ubuntu1.1 500
        500 http://ftp.uni-hannover.de/ubuntu focal-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
        100 /var/lib/dpkg/status
     2.3.1-9ubuntu1 500
        500 http://ftp.uni-hannover.de/ubuntu focal/main amd64 Packages

3) What you expected to happen:
Be able to log in at the local cups web interface with my domain user, which is in the lpadmin group

4) What happened instead:
Access was denied (asked again for my credentials)

[Christian Ehrhardt  (paelzer)]

Cups rightfully includes nameservices like:
    #include <abstractions/nameservice>

After our analysis in bug 1890858 I think it is fair to request an SRU update apparmor in Focal (only needed there, see bug 1890858 for details). As it would fix this element in Cups and actually in many other potential places as well.

Adding "unix (bind) type=dgram addr=@userdb-*," in abstractions/nameservice in Focal seems right to me.

---

Furthermore abstractions/nameservice already wants to allow sssd:

 37 # When using sssd, the passwd and group files are stored in an alternate path
 38 # and the nss plugin also needs to talk to a pipe
 39 /var/lib/sss/mc/group r,
 40 /var/lib/sss/mc/initgroups r,
 41 /var/lib/sss/mc/passwd r,
 42 /var/lib/sss/pipes/nss rw,

I don't know if
  /var/lib/sss/pipes/private/pam rw,
is a default configuration nor if it would be a safe path to allow.
But it could pretty much be.

If ok this one would likely be needed/wanted in >=Bionic into abstractions/nameservice

---

Both changes IMHO would have to be done by the security Team in regard to the apparmor package, therefore I'll add a bug task for this and assign them to have a look.

[Robert Euhus (euhus-liste1)]

Hi everyone,

It would be really nice to have any kind of feedback on this bug report. Is there anything else I can do? Do You need more info?

Thanks,
Robert

[Launchpad Janitor (janitor)]

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