Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) bind.c hard codes the output of the ssf= line in some of the stats logging to be zero, even if the connection actually has a higher ssf. For example: May 11 02:28:06 ldap01 slapd[33839]: conn=153267 fd=86 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1 tls_cipher=AES256-SHA May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0%%0 May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 RESULT tag=97 err=0 text= Note how we have mech=SIMPLE, ssf=0 Since we ran startTLS, and it was established, we clearly do NOT have an ssf of zero. the ssf=0 bit is *hard coded* in bind.c in the fe_op_bind_success function: /* log authorization identity */ Statslog( LDAP_DEBUG_STATS, "%s BIND dn=\"%s\" mech=%s ssf=0\n", op->o_log_prefix, op->o_conn->c_dn.bv_val, op->orb_mech.bv_val, 0, 0 ); There's a similar block in do_bind for anonymous binds as well: if ( !BER_BVISEMPTY( &op->o_conn->c_dn ) ) { /* log authorization identity demotion */ Statslog( LDAP_DEBUG_STATS, "%s BIND anonymous mech=implicit ssf=0\n", op->o_log_prefix, 0, 0, 0, 0 ); } It likely should be changed to use: op->o_conn->c_ssf
quanah@openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > bind.c hard codes the output of the ssf= line in some of the stats logging to be > zero, even if the connection actually has a higher ssf. For example: Works as designed. The Bind op itself didn't provide any security, so it contributed 0 to the session's ssf. The preceding StartTLS request actually established a security layer, and it correctly logs the ssf from that. Closing this ITS. > > May 11 02:28:06 ldap01 slapd[33839]: conn=153267 fd=86 TLS established > tls_ssf=256 ssf=256 tls_proto=TLSv1 tls_cipher=AES256-SHA > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" method=128 > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0%%0 > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 RESULT tag=97 err=0 text= > > > Note how we have mech=SIMPLE, ssf=0 > > Since we ran startTLS, and it was established, we clearly do NOT have an ssf of > zero. the ssf=0 bit is *hard coded* in bind.c in the fe_op_bind_success > function: > > /* log authorization identity */ > Statslog( LDAP_DEBUG_STATS, > "%s BIND dn=\"%s\" mech=%s ssf=0\n", > op->o_log_prefix, > op->o_conn->c_dn.bv_val, op->orb_mech.bv_val, 0, 0 ); > > > There's a similar block in do_bind for anonymous binds as well: > > if ( !BER_BVISEMPTY( &op->o_conn->c_dn ) ) { > /* log authorization identity demotion */ > Statslog( LDAP_DEBUG_STATS, > "%s BIND anonymous mech=implicit ssf=0\n", > op->o_log_prefix, 0, 0, 0, 0 ); > } > > It likely should be changed to use: > > op->o_conn->c_ssf > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Tuesday, May 12, 2015 1:18 PM +0000 hyc@symas.com wrote: > Works as designed. The Bind op itself didn't provide any security, so it > contributed 0 to the session's ssf. The preceding StartTLS request > actually established a security layer, and it correctly logs the ssf > from that. I think overall the design is problematic. "ssf" is generally supposed to indicate the overall security of the connection, regardless of the step. Perhaps for 2.5 and later, we could modify the logging line to be something more like: May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=256 So that the overall SSF of the connection is reflected, and we're indicating that specifically the BIND op added nothing to SSF. This would be useful for ldapi:/// connections as well, as there are zero ssf indicators logged at all outside of the bind op: May 12 02:30:19 ldap01 slapd[33839]: conn=169357 fd=85 ACCEPT from PATH=/opt/zimbra/data/ldap/state/run/ldapi (PATH=/opt/zimbra/data/ldap/state/run/ldapi) May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 RESULT tag=97 err=0 text= Even though I have: olcLocalSSF: 128 in my config DB I.e., I think it would be better to show: May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=128 in this case. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Tuesday, May 12, 2015 7:58 PM +0000 quanah@zimbra.com wrote: > --On Tuesday, May 12, 2015 1:18 PM +0000 hyc@symas.com wrote: > >> Works as designed. The Bind op itself didn't provide any security, so it >> contributed 0 to the session's ssf. The preceding StartTLS request >> actually established a security layer, and it correctly logs the ssf >> from that. > > I think overall the design is problematic. "ssf" is generally supposed to > indicate the overall security of the connection, regardless of the step. > Perhaps for 2.5 and later, we could modify the logging line to be > something more like: > > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=256 > > > So that the overall SSF of the connection is reflected, and we're > indicating that specifically the BIND op added nothing to SSF. > > This would be useful for ldapi:/// connections as well, as there are zero > ssf indicators logged at all outside of the bind op: > > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 fd=85 ACCEPT from > PATH=/opt/zimbra/data/ldap/state/run/ldapi > (PATH=/opt/zimbra/data/ldap/state/run/ldapi) > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" method=128 > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 RESULT tag=97 err=0 > text= > > > Even though I have: > > olcLocalSSF: 128 > > in my config DB > > I.e., I think it would be better to show: > > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=128 > > in this case. Per Howard: we should update the SASL Bind log to use bind_ssf= as well --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
2.5 work
changed notes moved from Incoming to Software Bugs
• 0d0d5072 by Quanah Gibson-Mount at 2020-06-21T22:04:46+00:00 ITS#8140 - Update bind operations to note bind_ssf vs overall connection ssf