Fix apparmor profile for Kerberos

I have a solution!

It was bl**dy app-armor preventing cupsd from reading /etc/krb5.keytab (required by PAM/Krb5) and apparantly preventing it writing a ticket cache into /tmp.

used aa-complain /usr/sbin/cupsd to disable AppArmor enforcement and that's fixed the problem.

I wonder how many other ubuntu/CUPS random crash bugs are due to AppArmor?...

*sigh*

This bug may be marked as closed - BUT if you care, you might consider disabling AppArmour, or putting in a big fat hairy warning on the CUPS webpages about it.

Cheers

Tim

Can you please reproduce the situation that caused an error before, and attach /var/log/kern.log? This will show me the exact violations that cause this. Thanks!

-- I emailed a reply but it didn;t appear, so I'm posting the text straight in

Hi Martin,

Sure - here you go:

Martin Pitt wrote:
> > Can you please reproduce the situation that caused an error before, and
> > attach /var/log/kern.log? This will show me the exact violations that
> > cause this. Thanks!
> >
> > ** Changed in: cupsys (Ubuntu)
> > Assignee: (unassigned) => Martin Pitt (pitti)
> > Status: New => Incomplete
> >

1st level failure after aa-enforce /usr/sbin/cups; /etc/init.d/cupsys
restart and then try to log into a secure cups page:

2009/02/13 09:41:07 notice kern rodan kernel: [558478.665721]
audit(1234518067.729:18151): type=1503 operation="inode_permission"
requested_mask="a::" denied_mask="a::" name="/dev/tty" pid=12486
profile="/usr/sbin/cupsd" namespace="default"
2009/02/13 09:41:07 notice kern rodan kernel: [558478.665903]
audit(1234518067.729:18152): type=1503 operation="inode_permission"
requested_mask="w::" denied_mask="w::" name="/etc/krb5.conf" pid=12486
profile="/usr/sbin/cupsd" namespace="default"

----

Then I add "/etc/krb5.conf r," to app-armour for usr.sbin.cupsd

Rinse, lather, repeat and we get:

2009/02/13 09:45:33 notice kern rodan kernel: [558743.850245]
audit(1234518333.342:18155): type=1503 operation="file_lock"
requested_mask="k::" denied_mask="k::" name="/etc/krb5.keytab" pid=12702
profile="/usr/sbin/cupsd" namespace="default"

So I add

/etc/krb5.keytab k,

(what's "k")?
----

Then we get:
2009/02/13 09:48:28 notice kern rodan kernel: [558918.559183]
audit(1234518508.333:18172): type=1503 operation="file_lock"
requested_mask="wk::" denied_mask="k::" name="/tmp/krb5cc_pam_CBTQ2A"
pid=13023 profile="/usr/sbin/cupsd" namespace="default"

(which is the kerberos ticket cache)

*Don't* assume the form of the name of that temp file - it's configurable.

So I add:
/tmp/** rkw,

-----

Re-init and that *seems* to work.

Kerberos auth via PAM is now operational.

But, I have little understanding of apparmor so you may be able to see
sillyness in what I've done.

Cheers - and thanks :)

Glad to be able to help make a great distro 0.0001% better :)

Best wishes

Tim

> audit(1234518067.729:18152): type=1503 operation="inode_permission"
> requested_mask="w::" denied_mask="w::" name="/etc/krb5.conf" pid=12486
> profile="/usr/sbin/cupsd" namespace="default"

This looks worrysome. Why does it want to write ("w") krb5.conf? ...

> Then I add "/etc/krb5.conf r," to app-armour for usr.sbin.cupsd

Anyway, you only gave it read permissions, which should really be sufficient. Since you say that works, all is great.

'k' means "lock", BTW, i. .e you can call flock() on a file. It's rather harmless.

So I'll add those changes to the cups profile.

Thank you!

> This looks worrysome. Why does it want to write ("w") krb5.conf? ...

This has been a long lasting issue around the kerberos libraries that has been seen in both the apparmor and SELinux communities; according to http://www.nsa.gov/research/selinux/list-archive/0312/thread_body13.shtml#6196 , what krb5 is doing is an access(2) call to see if it has write access to the conf file or not. Unfortunately, this ends being passed to the LSM layer as a live permission check, and results in the rejection message you see above. There's been proposals amongst the apparmor developers to support something akin to SELinux's dontaudit keyword, which would reject but not log access attempts (on a per-rule basis), but it's never been a priority because this one case has been the only one we've seen where we wanted it.

(In ancient pre-LSM days, apparmor would only do permission checks on actual accesses, not the access(2) call, but the ability to distinguish between an access(2) call and a regular open(2) call was not included when the LSM api was created.)

Thanks, Steve, for the heads-up.

This bug was fixed in the package cups - 1.3.9-15

---------------
cups (1.3.9-15) unstable; urgency=low

  * Add debian/local/apport-hook.py: Apport package hook, thanks to
    Brian Murray! Install it in debian/rules if we build for Ubuntu.
    (LP: #334080)
  * debian/rules: Move init script priority to 50, so that cups starts later
    in the boot sequence. There is no reason why it should start so early
    (before e. g. gdm). Do the transition on upgrades in debian/cups.postinst.
  * debian/control: Promote ttf-freefont from Recommends to Depends, since the
    PDF filter chain needs it. (Closes: #516335)
  * debian/control: Add "Breaks: foomatic-filters (<< 4.0)", and bump
    Recommends: version. Earlier foomatic-filters do not support the PDF
    filter chain. (Closes: #511009)
  * debian/local/apparmor-profile: Add a few missing rules for Kerberos
    authentication. (LP: #324645)
  * Add bzr-builddeb configuration (merge mode).
  * debian/watch: Update so that it works again.
  * debian/local/apparmor-profile: Allow cups to read /etc/likewise, for
    authentication. (LP: #303927)
  * Add testsuite-increase-wait-timeout.dpatch: Increase test suite's timeout
    for waiting for jobs to 10 minutes, for slower architectures like arm and
    m68k. (Closes: #518787)

 -- Martin Pitt <email address hidden> Tue, 10 Mar 2009 13:46:19 +0100