Skip Menu |
 

History Show all quoted text — Show full headers
# Thu Dec 13 17:24:19 2012 The RT System itself - Ticket created
Download (untitled) / with headers
text/plain 6.4KiB
From krb5-bugs-incoming-bounces@PCH.mit.edu Thu Dec 13 17:24:19 2012
Return-Path: <krb5-bugs-incoming-bounces@PCH.mit.edu>
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
by krbdev.mit.edu (Postfix) with ESMTP id D6D263F00B;
Thu, 13 Dec 2012 17:24:18 -0500 (EST)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id qBDMOICf024067;
Thu, 13 Dec 2012 17:24:18 -0500
Received: from mailhub-dmz-2.mit.edu (MAILHUB-DMZ-2.MIT.EDU [18.7.62.37])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id qBDMH2Vs023206
for <krb5-bugs-incoming@PCH.mit.edu>; Thu, 13 Dec 2012 17:17:02 -0500
Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU
[18.9.25.13])
by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id qBDMGu27002869
for <krb5-bugs@mit.edu>; Thu, 13 Dec 2012 17:17:01 -0500
X-AuditID: 1209190d-b7f266d00000092b-10-50ca53dd1a96
Authentication-Results: symauth.service.identifier; spf=pass; senderid=pass
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP
id D3.B9.02347.DD35AC05; Thu, 13 Dec 2012 17:17:01 -0500 (EST)
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBDMH0GB025764
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
for <krb5-bugs@mit.edu>; Thu, 13 Dec 2012 17:17:00 -0500
Received: from blade.bos.redhat.com (blade.bos.redhat.com [10.16.184.36])
by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
id qBDMGxgw005448
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <krb5-bugs@mit.edu>; Thu, 13 Dec 2012 17:17:00 -0500
Received: from blade.bos.redhat.com (localhost.localdomain [127.0.0.1])
by blade.bos.redhat.com (8.14.5/8.14.5) with ESMTP id qBDMH6ar011424
for <krb5-bugs@mit.edu>; Thu, 13 Dec 2012 17:17:06 -0500
Received: (from nalin@localhost)
by blade.bos.redhat.com (8.14.5/8.14.5/Submit) id qBDMH5Ga011423;
Thu, 13 Dec 2012 17:17:05 -0500
Date: Thu, 13 Dec 2012 17:17:05 -0500
Message-Id: <201212132217.qBDMH5Ga011423@blade.bos.redhat.com>
To: krb5-bugs@mit.edu
Subject: kldap plugin always writes to krbLastAdminUnlock
From: nalin@redhat.com
X-send-pr-version: 3.99
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleJIrShJLcpLzFFi42K52LJdRvdu8KkAg1+PNS0aHh5nd2D0aDpz
lDmAMYrLJiU1J7MstUjfLoErY1HnVtaC4+IVrc0bWBsYO4W6GDk5JARMJBbeaWQEsRkFvCXe
XD3ODhEXk7hwbz1bFyMXh5DACUaJec0/2SGcTUwSj1/cYIRwljJJPJr+jxXCOckoce7QIaiy
NkaJ57cvgg1jEVCVuPR2FpjNK2AnsfLAJ1YQW0RAVOLl32MsILawgKXEptcTmUBsNqDlN+ad
AqsREpCSaL80nQ3EZhZgkfjzZgMLxIHiEju2n4Y6Vlvic/NMlgmMggsYGVYxyqbkVunmJmbm
FKcm6xYnJ+blpRbpGunlZpbopaaUbmIEhpoQpyTvDsZ3B5UOMQpwMCrx8E7gPBUgxJpYVlyZ
e4hRkoNJSZRX3RsoxJeUn1KZkVicEV9UmpNafIhRgoNZSYS31w8ox5uSWFmVWpQPk5LmYFES
572SctNfSCA9sSQ1OzW1ILUIJsvEwX6IUYaDQ0mC93UQULdgUWp6akVaZk4JshpOEMEFsoYH
aM0VkELe4oLE3OLMdIiiU4y6HIuX3HzKKMSSl5+XKiXOOxukSACkKKM0D24YLG1cYpSVEuZl
ZGBgEOIBugYYCKjyrxjFgQEgDDGFJzOvBG7TK6AjmICOiLt0HOSIkkSElFQDY2tbj6Z9b+/h
0m+vK1OTQ+d9dtrwxDB0bty+aUHxQhun/5xseWLrq7WvJ+zY5PfCo6HPJNPANWqu7NOy45Um
u/9tmaPeopl9btcFOctG5zwRg0drixddDXKKYlm/uLbL6/7epu23j5s/PsN1waZ2avzMWQH5
cc4vnsVHriouy7BKqtsTefB0rhJLcUaioRZzUXEiAElhC9cWAwAA
X-Mailman-Approved-At: Thu, 13 Dec 2012 17:24:17 -0500
X-BeenThere: krb5-bugs-incoming@mailman.mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: nalin@redhat.com
Sender: krb5-bugs-incoming-bounces@PCH.mit.edu
Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu


Show quoted text
>Submitter-Id: net
>Originator:
>Organization: Red Hat
>Confidential: no
>Synopsis: kldap plugin always writes to krbLastAdminUnlock
>Severity: non-critical
>Priority: low
>Category: krb5-kdc
>Class: change-request
>Release: 1.10.3
>Environment:

System: Linux blade.bos.redhat.com 3.6.9-4.fc18.x86_64 #1 SMP Tue Dec 4 14:12:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64

Show quoted text
>Description:
When the kldap plugin is being used for accessing the realm
database, if an administrator ever uses kadmin to manually
unlock an entry in the database, an entry will have a
krbLastAdminUnlock added to it.
We've gotten a report that after that happens, whenever a KDC
attempts to audit log an AS request, the KDC will attempt to
write the current value of the entry's krbLastAdminUnlock
attribute to the entry. In deployments where the KDC's write
access is restricted to specific attributes, this will fail.
Show quoted text
>How-To-Repeat:
Set up a KDC and directory server using the kldap db2 module,
and either tcpdump or directory server logging to observe any
LDAP modify requests that the KDC makes.
Either create a new client entry with the preauth-required flag
set on it, or choose an already-created one and ensure that it
doesn't have a krbLastAdminUnlock value in its entry.
Apply a policy to the client entry that includes lockout-related
parameters.
Use kinit to obtain new credentials as the client.
Use "modprinc -unlock" to set a krbLastAdminUnlock value on the
client entry.
Use kinit to obtain new credentials as the client.
Compare the set of attributes which the KDC attempted to modify
in the entry after each successful AS request. The second set
will unnecessarily include krbLastAdminUnlock.
Show quoted text
>Fix:
It's not particularly elegant, but this appears to work:

Try to avoid writing krbLastAdminUnlock when we're just doing auditing
in the KDC. Because we know that kdb5_ldap_put_principal() only writes
the attribute when it's nonzero, we temporarily set the value to zero to
make sure that it isn't written.

--- src/plugins/kdb/ldap/libkdb_ldap/lockout.c
+++ src/plugins/kdb/ldap/libkdb_ldap/lockout.c
@@ -217,8 +217,14 @@ krb5_ldap_lockout_audit(krb5_context context,
}

if (entry->mask) {
- code = krb5_ldap_put_principal(context, entry, NULL);
- if (code != 0)
+ /* temporarily clear the last-admin-unlock time so that we don't try
+ * to write to it -- we're just here to update audit data */
+ if ((code = krb5_dbe_lookup_last_admin_unlock(context, entry,
+ &unlock_time)) ||
+ (code = krb5_dbe_update_last_admin_unlock(context, entry, 0)) ||
+ (code = krb5_ldap_put_principal(context, entry, NULL)) ||
+ (code = krb5_dbe_update_last_admin_unlock(context, entry,
+ unlock_time)))
return code;
}

# Thu Dec 13 17:24:19 2012 The RT System itself - Tags enhancement added
# Thu Dec 13 17:24:19 2012 The RT System itself - Component krb5-kdc added
# Thu Dec 13 18:05:20 2012 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 687B
The problem seems bigger than just this symptom:

* krb5_ldap_put_principal doesn't check whether KADM5_TL_DATA is set in
entry->mask. So any tl_data in the principal will be written out in any
update, whether normalized to type-specific LDAP attributes or marshalled
into krbExtraData. If you're going to use the patch you provided as a
downstream workaround, I'd suggest nulling out entry->tl_data temporarily
instead of just resetting the last-admin-unlock value.

* There's no way to specify via entry->mask which tl_data values should be
written out, and which were just along for the ride from a previous fetch.
Fixing that seems like a somewhat difficult design problem.
# Thu Dec 13 18:06:26 2012 ghudson@mit.edu (Greg Hudson) - Correspondence added
Download (untitled) / with headers
text/plain 173B
Actually, I guess nulling out entry->tl_data could be a problem if the
LDAP back end has encoded stuff like the DN in there. So maybe that's not
a good workaround either.
# Thu Dec 13 18:09:21 2012 <nalin@redhat.com> - Correspondence added
Date: Thu, 13 Dec 2012 18:09:25 -0500
From: Nalin Dahyabhai <nalin@redhat.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #7502] kldap plugin always writes to krbLastAdminUnlock
RT-Send-Cc:
Download (untitled) / with headers
text/plain 609B
On Thu, Dec 13, 2012 at 06:05:20PM -0500, Greg Hudson via RT wrote:
Show quoted text
> The problem seems bigger than just this symptom:

Agreed.

Show quoted text
> * krb5_ldap_put_principal doesn't check whether KADM5_TL_DATA is set in
> entry->mask. So any tl_data in the principal will be written out in any
> update, whether normalized to type-specific LDAP attributes or marshalled
> into krbExtraData. If you're going to use the patch you provided as a
> downstream workaround, I'd suggest nulling out entry->tl_data temporarily
> instead of just resetting the last-admin-unlock value.

Yes, I think that'll work.

Thanks,

Nalin