Re: (ITS#8909) "authz-policy all" works as "authz-policy any", possibly yielding unauthorized access
by hyc@symas.com
guilhem(a)fripost.org wrote:
> Full_Name: Guilhem Moulin
> Version: 2.4.44
> OS: Debian GNU/Linux (Stretch)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (109.225.112.70)
>=20
>=20
> slapd.conf(5) manpage (in both 2.4.44 and in current =E2=80=94 0f320b3 =
=E2=80=94 master)
> mentions that authz-policy's "all" flag requires both source and destin=
ations
> authorizations rules to succeed. However if the source rule (the authe=
ntication
> identity's "authzTo" attribute) fails but the destination rule (the
> authorization identity's "authzFrom" attribute) succeeds, then the auth=
orization
> is granted, violating the intended semantics and possibly yielding unau=
thorized
> access. See the following log excerpt:
Thanks for the report. Looks like this has been present since commit 1137=
27ba.
Fixed now in git master
>=20
> SASL proxy authorize [conn=3D1019]: authcid=3D"authcid"
> authzid=3D"dn:uid=3Dauthzid,dc=3Dexample,dc=3Dnet"
> =3D=3D>slap_sasl_authorized: can uid=3Dauthcid,dc=3Dexample,dc=3Dnet be=
come
> uid=3Dauthzid,dc=3Dexample,dc=3Dnet?
> =3D=3D>slap_sasl_check_authz: does uid=3Dauthzid,dc=3Dexample,dc=3Dnet =
match authzTo rule
> in uid=3Dauthcid,dc=3Dexample,dc=3Dnet?
> <=3D=3Dslap_sasl_check_authz: authzTo check returning 50
> =3D=3D>slap_sasl_check_authz: does uid=3Dauthcid,dc=3Dexample,dc=3Dnet =
match authzFrom
> rule in uid=3Dauthzid,dc=3Dexample,dc=3Dnet?
> <=3D=3D=3Dslap_sasl_match: comparison returned 0
> <=3D=3Dslap_sasl_check_authz: authzFrom check returning 0
> <=3D=3D slap_sasl_authorized: return 0
> conn=3D1019 op=3D1 BIND authcid=3D"authcid"
> authzid=3D"dn:uid=3Dauthzid,dc=3Dexample,dc=3Dnet"
> SASL Authorize [conn=3D1019]: proxy authorization allowed
> authzDN=3D"uid=3Dauthzid,dc=3Dexample,dc=3Dnet"
>=20
> AFAICT the problem is in servers/slapd/saslauthz.c:slap_sasl_authorized=
(), and
> is also present in master. Here is a naive patch that fails the author=
ization
> if the source rules doesn't verify and SASL_AUTHZ_AND is set in authz_p=
olicy.
>=20
> --- a/servers/slapd/saslauthz.c
> +++ b/servers/slapd/saslauthz.c
> @@ -2077,6 +2077,10 @@ int slap_sasl_authorized( Operation *op,
> if( rc =3D=3D LDAP_SUCCESS && !(authz_policy & SASL_AUTHZ_AND)=
) {
> goto DONE;
> }
> + else if( rc !=3D LDAP_SUCCESS && (authz_policy & SASL_AUTHZ_AN=
D) ) {
> + rc =3D LDAP_INAPPROPRIATE_AUTH;
> + goto DONE;
> + }
> }
> =20
> /* Check destination rules */
>=20
>=20
--=20
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2 years, 4 months
(ITS#8909) "authz-policy all" works as "authz-policy any", possibly yielding unauthorized access
by guilhem@fripost.org
Full_Name: Guilhem Moulin
Version: 2.4.44
OS: Debian GNU/Linux (Stretch)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (109.225.112.70)
slapd.conf(5) manpage (in both 2.4.44 and in current 0f320b3 master)
mentions that authz-policy's "all" flag requires both source and destinations
authorizations rules to succeed. However if the source rule (the authentication
identity's "authzTo" attribute) fails but the destination rule (the
authorization identity's "authzFrom" attribute) succeeds, then the authorization
is granted, violating the intended semantics and possibly yielding unauthorized
access. See the following log excerpt:
SASL proxy authorize [conn=1019]: authcid="authcid"
authzid="dn:uid=authzid,dc=example,dc=net"
==>slap_sasl_authorized: can uid=authcid,dc=example,dc=net become
uid=authzid,dc=example,dc=net?
==>slap_sasl_check_authz: does uid=authzid,dc=example,dc=net match authzTo rule
in uid=authcid,dc=example,dc=net?
<==slap_sasl_check_authz: authzTo check returning 50
==>slap_sasl_check_authz: does uid=authcid,dc=example,dc=net match authzFrom
rule in uid=authzid,dc=example,dc=net?
<===slap_sasl_match: comparison returned 0
<==slap_sasl_check_authz: authzFrom check returning 0
<== slap_sasl_authorized: return 0
conn=1019 op=1 BIND authcid="authcid"
authzid="dn:uid=authzid,dc=example,dc=net"
SASL Authorize [conn=1019]: proxy authorization allowed
authzDN="uid=authzid,dc=example,dc=net"
AFAICT the problem is in servers/slapd/saslauthz.c:slap_sasl_authorized(), and
is also present in master. Here is a naive patch that fails the authorization
if the source rules doesn't verify and SASL_AUTHZ_AND is set in authz_policy.
--- a/servers/slapd/saslauthz.c
+++ b/servers/slapd/saslauthz.c
@@ -2077,6 +2077,10 @@ int slap_sasl_authorized( Operation *op,
if( rc == LDAP_SUCCESS && !(authz_policy & SASL_AUTHZ_AND) ) {
goto DONE;
}
+ else if( rc != LDAP_SUCCESS && (authz_policy & SASL_AUTHZ_AND) ) {
+ rc = LDAP_INAPPROPRIATE_AUTH;
+ goto DONE;
+ }
}
/* Check destination rules */
2 years, 4 months
Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by subbarao@computer.org
On 08/26/2018 03:07 PM, Ryan Tandy wrote:
> If I create a patch to log some additional debug info about the GnuTLS
> setup, would you be willing to run it in your environment? For example
> I'm curious whether EAGAIN is being returned from the read side or
> write side (guessing read, but would be nice to confirm).
Sure, send me the patch. If the patch just does some additional GnuTLS
logging, then I don't see a problem with running it in the production
environment and sending you the results.
Regards,
-Kartik
2 years, 4 months
(ITS#8908) LMDB Documentation for MDB_XXX_MULTIPLE
by karl@waclawek.net
Full_Name: Karl Waclawek
Version: LMDB 0.9.22
OS: Windows 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2607:fea8:7a80:814:3ca9:e8f6:801c:d6f8)
The documentation in lmdb.h for MDB_GET_MULTIPLE, MDB_NEXT_MULTIPLE and
MDB_PREV_MULTIPLE seems to have two issues:
1) The documentation indicates that both, the key and data, are returned, but in
reality only the data is returned.
2) The documentation states that MDB_GET_MULTIPLE moves the cursor. This does
not seem to be true.
2 years, 4 months
Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by ryan@nardis.ca
Hi Karthik,
Sorry about the lack of updates on this one.
It looks clear that my patch for this ITS was wrong and needs to be
reverted.
Looking again at the original issue, after reverting the patch, I've
found that the behaviour varies with GnuTLS version. I need to figure
out why this is, which probably means spending some time bisecting
GnuTLS changes.
If I create a patch to log some additional debug info about the GnuTLS
setup, would you be willing to run it in your environment? For example
I'm curious whether EAGAIN is being returned from the read side or write
side (guessing read, but would be nice to confirm).
thanks
Ryan
2 years, 4 months
(ITS#8907) Memory leak on mass adding users to ldap
by nowhereman@nowhereman.ru
Full_Name: Alexey Karpov
Version: 2.4.44
OS: RHEL 7.5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (87.245.195.105)
We have two OpenLDAP servers version 2.4.44, running on RHEL 7.5, replicated in
mirror mode and working as active-standby. OpenLDAP works as userstore for WSO2
Identity Server. Servers configured with tls security and valid certificates.
All requests come to first server (ldap1), second server (ldap2) working as
reserve.
When we start batch adding users (about 3-5 inserts per second, mixed with
queries and changing values), we observe a memory leak on server ldap1,
load-dependent, up to gigabyte per minute, and the lag in sync between servers.
If we stop server ldap2, leaking stops and server ldap1 working properly. Memory
is not freeing until server is restarted.
Also we try this setup with version 2.4.44 on Centos 7 and custom builded
version 2.4.46 on Centos 7. Results are the same - on batch adding users,
server, receiving requests has memory leak and leaking stops when second server
stopped.
2 years, 4 months
(ITS#8905) Client side debug log should include timestamps
by quanah@openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.46
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
When specifying full debug on the client side (-d -1), there are no timestamps
provided. This is problematic when trying to diagnose where the client side is
having issues when connecting to the slapd server. I.e., an ldapwhoami command
that takes 19 seconds to go from start to finish, while the slapd side shows
everything taking 1 second or less.
2 years, 4 months
(ITS#8904) Cannot enable SSL3 when disabled by default in OpenSSL
by mhonek@redhat.com
Full_Name: Matus Honek
Version: 2.4.46
OS: Fedora 28
URL: ftp://ftp.openldap.org/incoming/Matus-Honek-180821.patch
Submission from: (NULL) (213.175.37.10)
When in OpenSSL one disables SSL3 by default (the SSL_OP_NO_SSLv3 is set by
default, like in recent Fedora distributions) then with the current code in
OpenLDAP it is not possible to have it re-enabled using TLS_PROTOCOL_MIN
configuration option.
The attached patch explicitly clears the SSL_OP_NO_SSLv3 option when
TLS_PROTOCOL_MIN is set so that SSL3 should be enabled. Feel free to use it; I
believe IPR should not be necessary for a one liner.
However, in the future when more protocols will be disabled by default (possibly
soon for TLS1.0 and TLS1.1), similar fixes will be needed for those as well. Or,
it may be decided to not support the protocols that are disabled by default but
in that case probably a log message should be issued once user tries to enable a
by default disabled protocol.
2 years, 4 months
RE: (ITS#8848) New LDAP URL syntax to support binding to specific IP address at client side
by sudhir.singam@nokia.com
Hi,
Any comments ??
Regards,
Sudhir Singam
DELIVERING BEST-IN-CLASS PLATFORM is our vision
-----Original Message-----
From: openldap-its(a)OpenLDAP.org <openldap-its(a)OpenLDAP.org>=20
Sent: Monday, May 07, 2018 12:02 PM
To: Singam, Sudhir (Nokia - IN/Bangalore) <sudhir.singam(a)nokia.com>
Subject: Re: (ITS#8848) New LDAP URL syntax to support binding to specific =
IP address at client side
*** THIS IS AN AUTOMATICALLY GENERATED REPLY ***
Thanks for your report to the OpenLDAP Issue Tracking System. Your
report has been assigned the tracking number ITS#8848.
One of our support engineers will look at your report in due course.
Note that this may take some time because our support engineers
are volunteers. They only work on OpenLDAP when they have spare
time.
If you need to provide additional information in regards to your
issue report, you may do so by replying to this message. Note that
any mail sent to openldap-its(a)openldap.org with (ITS#8848)
in the subject will automatically be attached to the issue report.
mailto:openldap-its@openldap.org?subject=3D(ITS#8848)
You may follow the progress of this report by loading the following
URL in a web browser:
http://www.OpenLDAP.org/its/index.cgi?findid=3D8848
Please remember to retain your issue tracking number (ITS#8848)
on any further messages you send to us regarding this report. If
you don't then you'll just waste our time and yours because we
won't be able to properly track the report.
Please note that the Issue Tracking System is not intended to
be used to seek help in the proper use of OpenLDAP Software.
Such requests will be closed.
OpenLDAP Software is user supported.
http://www.OpenLDAP.org/support/
--------------
Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.
2 years, 4 months