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.
** Also affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
** Changed in: apparmor (Ubuntu)
Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1932537
Title:
CUPS + SSSD: cannot access local CUPS web interface with domain user
(apparmor problem)
Status in apparmor package in Ubuntu:
New
Status in cups package in Ubuntu:
New
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.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)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1932537/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
