** 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 -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
