[Bug 1783183] Re: apparmor profile denied for kerberos client keytab and credential cache files

[Andreas Hasenack]

** Description changed:

  [Impact]
+ When using syncrepl replication with openldap, the consumer needs to authenticate to the provider in order to perform the searches and fetch the data. When this authentication is a simple bind, a simple username/password pair is used and that can be easily supplied in a configuration file.
  
-  * An explanation of the effects of the bug on users and
+ When one wants to use a stronger authentication mechanism, like gssapi
+ (kerberos), the authentication is based on keytab files and tickets. The
+ consumer needs to obtain a ticket from the KDC, and use that ticket to
+ authenticate itself with the provider.
  
-  * justification for backporting the fix to the stable release.
+ For users, it's a simple matter of running kinit(1) and providing a
+ password. For services, the solution is to extract the key from the KDC
+ and store it in a local keytab file, which is then used by the service
+ to obtain the TGT.
  
-  * In addition, it is helpful, but not required, to include an
-    explanation of how the upload fixes this bug.
+ Problem is this TGT expires, and needs to be renewed periodically.
+ Solutions have popped up for that issue, the most famous one being
+ kstart (https://www.eyrie.org/~eagle/software/kstart/), but since the
+ MIT kerberos 1.11 release, there is a simpler way.
+ 
+ Via the default_client_keytab_name krb5.conf(5) option, one can specify
+ the default location of a keytab file per local user. The kerberos
+ library will then automatically use that file to obtain the TGT, and
+ proceed as usual from there.
+ 
+ The default value of that setting is /etc/krb5/user/<uid>/client.keytab.
+ 
+ Turns out the openldap slapd apparmor profile doesn't account for that,
+ and blocks attempts to read that file. It also blocks reading the TGT
+ that is obtained and stored in /tmp/krb5cc_<uid>, resulting in such
+ DENIED errors in the logs:
+ 
+ apparmor="DENIED" operation="open" profile="/usr/sbin/slapd"
+ name="/etc/krb5/user/389/client.keytab" pid=19080 comm="slapd"
+ requested_mask="r" denied_mask="r" fsuid=389 ouid=389
+ 
+ apparmor="DENIED" operation="file_lock" profile="/usr/sbin/slapd"
+ name="/tmp/krb5cc_389" pid=19080 comm="slapd" requested_mask="k"
+ denied_mask="k" fsuid=389 ouid=389
+ 
+ Since the slapd apparmor is enabled by default, this blocks the usage of
+ this very helpful feature. Also considering that kerberos/gssapi errors
+ are usually hard to debug, it might take a while for an admin to figure
+ out what is going on.
+ 
+ The fix is to update the apparmor profile and allow access to those
+ files. Unfortunately there are no rich globbing rules for paths in an
+ apparmor profile, nothing like @{uid} of the current process yet, or a
+ regexp rule like [0-9]+, so the rules have to be a bit accomodating. For
+ this bug, I came up with these two new lines:
+ 
+   /etc/krb5/user/*/client.keytab kr,
+   owner /tmp/krb5cc_* rwk,
+ 
+ One could relax the first one perhaps into something like /etc/krb5/**,
+ but the above works with the default settings.
+ 
  
  [Test Case]
  
-  * detailed instructions how to reproduce the bug
+  * detailed instructions how to reproduce the bug
  
-  * these should allow someone who is not familiar with the affected
-    package to reproduce the bug and verify that the updated package fixes
-    the problem.
+  * these should allow someone who is not familiar with the affected
+    package to reproduce the bug and verify that the updated package fixes
+    the problem.
  
  [Regression Potential]
  
-  * discussion of how regressions are most likely to manifest as a result
+  * discussion of how regressions are most likely to manifest as a result
  of this change.
  
-  * It is assumed that any SRU candidate patch is well-tested before
-    upload and has a low overall risk of regression, but it's important
-    to make the effort to think about what ''could'' happen in the
-    event of a regression.
+  * It is assumed that any SRU candidate patch is well-tested before
+    upload and has a low overall risk of regression, but it's important
+    to make the effort to think about what ''could'' happen in the
+    event of a regression.
  
-  * This both shows the SRU team that the risks have been considered,
-    and provides guidance to testers in regression-testing the SRU.
+  * This both shows the SRU team that the risks have been considered,
+    and provides guidance to testers in regression-testing the SRU.
  
  [Other Info]
-  
-  * Anything else you think is useful to include
-  * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
-  * and address these questions in advance
  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
+  * and address these questions in advance
  
  [Original Description]
  
  Can we get /etc/krb5/** and /tmp/krb5cc_* added with the appropriate
  permissions to the slapd apparmor profile? I'm getting the following
  kinds of errors:
  
  apparmor="DENIED" operation="open" profile="/usr/sbin/slapd"
  name="/etc/krb5/user/389/client.keytab" pid=19080 comm="slapd"
  requested_mask="r" denied_mask="r" fsuid=389 ouid=389
  
  apparmor="DENIED" operation="file_lock" profile="/usr/sbin/slapd"
  name="/tmp/krb5cc_389" pid=19080 comm="slapd" requested_mask="k"
  denied_mask="k" fsuid=389 ouid=389

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

Title:
  apparmor profile denied for kerberos client keytab and credential
  cache files

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