CUPS + SSSD: cannot access local CUPS web interface with domain user (apparmor problem)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
apparmor (Ubuntu) |
Confirmed
|
Undecided
|
Ubuntu Security Team | ||
cups (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
[Summary]
My domain user can not access the local CUPS web interface due to apparmor denials.
Adding the following two lines to /etc/apparmor.
/var/lib/
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=
This already existed in Bionic and my workaround was to add '/var/lib/
# echo '/var/lib/
# apparmor_parser -r -W -T /etc/apparmor.
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=
This looks very similar to https:/
# echo 'unix (bind) type=dgram addr=@userdb-*,' >> /etc/apparmor.
# apparmor_parser -r -W -T /etc/apparmor.
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:/
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
Installations
Versionstabelle:
*** 2.3.1-9ubuntu1.1 500
500 http://
500 http://
100 /var/lib/
2.3.1-9ubuntu1 500
500 http://
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)
Cups rightfully includes nameservices like: nameservice>
#include <abstractions/
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 sss/mc/ group r, sss/mc/ initgroups r, sss/mc/ passwd r, sss/pipes/ nss rw,
38 # and the nss plugin also needs to talk to a pipe
39 /var/lib/
40 /var/lib/
41 /var/lib/
42 /var/lib/
I don't know if lib/sss/ pipes/private/ pam rw,
/var/
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.