AppArmor denying CUPS authentication against PAM on AD joined system (SSSD-based)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
AppArmor |
New
|
Undecided
|
Unassigned | ||
apparmor (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
System information:
OS: Ubuntu 14.04.4 LTS
AppArmor 2.8.95~
SSSD: 1.11.5-1ubuntu3
CUPS: 1.7.2-0ubuntu1.7
I believe this is a bug that belongs here rather than with SSSD or CUPS package; apologies if incorrect.
The problem arises when attempting to grant non-local end user accounts (e.g, domain accounts) extra permissions to modify portions of the Admin page, so that they can add/remove printers themselves for instance. There's a few ways to do this, obviously, such as adding extra groups or users to the SystemGroup definition in /etc/cups-files, or adding "Require valid-user" to the <Location /admin> location in /etc/cupsd.conf.
Attempting to alter SystemGroup by adding "Domain Users", or by adding the "Require valid-user" statement to the /admin location definition causes the CUPS web page (http://
Digging through logs, it becomes apparent that CUPS appears to rely on PAM for authentication - error messages appear in /var/log/auth.log like so:
Mar 15 07:53:41 <pc name redacted> cupsd: pam_unix(
Mar 15 07:53L31 <pc name redacted> cupsd: pam_sss(cups:auth): Request to sssd failed. Permission denied
The first line is expected, as a network account will not be auth'd by pam_unix. The second line points to the problem: when CUPS attempts to talk to sssd (indirectly by invoking PAM, but it still happens) then CUPS is blocked with a permission denied.
Further research turned up a prior bug report (1264548, https:/
[21507.848482] type=1400 audit(145806744
Further evidence can be found in the fact that setting the CUPS profile to complain mode in AppArmor causes the problem to go away (both Kerberos and Basic authentication modes work).
I have successfully resolved the issue locally by adding the rule
/var/lib/
to the file /etc/apparmor.
Looking at /etc/apparmor.
I also don't know what, if any, wider security issues there may be from granting CUPS access to /var/lib/
Hi Doug - Thank you for the excellent bug report!
Since we're preparing for the upstream AppArmor 2.11 release, I took a look to see if I could fix this bug prior to the release. Unfortunately, I didn't have time to get to the bottom of what the significance is of the private (sometimes referred to as privileged in the source code) pipe is.
Without understanding the importance of the pipe, I didn't want to rush into granting access from cupsd.
I'm glad that you have a workaround to unblock yourself and I hope that we can better understand the usage of that particular pipe to make a judgement call on adding the rule in the upstream policy.
Thanks again!