Public bug reported:

System information:

OS: Ubuntu 14.04.4 LTS
AppArmor 2.8.95~2430-0ubuntu5.3
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://localhost:631) to reject all network
users credentials.  The valid-user option will cause CUPS to accept
local user account credentials regardless of whether they have root
access or are part of lpadmin.  Interestingly, both BasicAuthentication
and Kerberos (Negotiate) authentication modes cause network accounts to
be rejected .

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(cups:auth): authentication 
failure; logname= uid=0 euid=0 tty=cups ruser= rhost=localhost user=<network 
user name>
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://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1264548) that
highlighted nearly the same problem and highlighting it as an AppArmor
rejection.  Examining the output of `dmesg | grepDENIED.*cups`, we do
see lines in the output:

[21507.848482] type=1400 audit(1458067443.626:435): apparmor="DENIED"
operation="connect" profile="/usr/sbin/cupsd"
name="/var/lib/sss/pipes/private/pam" pid=27447 comm="cupsd"
requested_mask="rw" denied_mask="rw" fsuid=0 ouid=0

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/sss/pipes/private/pam rw,

to the file /etc/apparmor.d/local/usr.sbin.cupsd.  Interestingly, this
also resolves the kerberos issue - both 'DefaultAuthType Basic' and
'DefaultAuthType Negotiate' will successfully allow network accounts to
access the Administration page.

Looking at /etc/apparmor.d/usr.sbin.cupsd, it includes the
abstractions/authentication def file, which in turn contains a specific
include for the abstractions/winbind file.  I don't know whether there
should be an equivalent abstractions file for sssd; the one line fix
above really doesn't by itself warrant a full separate file, but if
there are perhaps other sssd specific definitions that contained
applications may need access to, perhaps that would warrant a separate
file.

I also don't know what, if any, wider security issues there may be from
granting CUPS access to /var/lib/sss/pipes/private/pam, either, so
perhaps a different proper fix would be required?

** Affects: apparmor (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: activedirectory apparmor authentication cups sssd

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1558753

Title:
  AppArmor denying CUPS authentication against PAM on AD joined system
  (SSSD-based)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1558753/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to