Debian Bug report logs - #368297
sudo-ldap failes when you change uri to ldaps

Package: libgcrypt11; Maintainer for libgcrypt11 is Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>; Source for libgcrypt11 is src:libgcrypt11.

Reported by: Alexander Samad <alex@samad.com.au>

Date: Sun, 21 May 2006 09:48:01 UTC

Severity: serious

Tags: help, patch, squeeze-ignore, wheezy-ignore

Merged with 545414, 566351, 579647, 601667, 628671, 658739, 658896

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. Full text and rfc822 format available.

Acknowledgement sent to Alexander Samad <alex@samad.com.au>:
New Bug report received and forwarded. Copy sent to Bdale Garbee <bdale@gag.com>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Alexander Samad <alex@samad.com.au>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: sudo-ldap failes when you change uri to ldaps
Date: Sun, 21 May 2006 19:25:38 +1000
Package: sudo-ldap
Version: 1.6.8p12-4
Severity: grave
Justification: renders package unusable

Hi

I have setup sudo-ldap to use the local ldap db. My /etc/ldap/ldap.conf
has

uri ldap://127.0.0.1

when I change this to 

uri ldaps://hufpuf.lan1.hme1.samad.com.au

it faills and I get with with debuging turned on

LDAP Config Summary
===================
uri          ldaps://hufpuf.lan1.hme1.samad.com.au
ldap_version 3
sudoers_base ou=SUDOers,dc=samad,dc=com,dc=au
binddn       (anonymous)
bindpw       (anonymous)
ssl          (no)
===================
ldap_initialize(ld,ldaps://hufpuf.lan1.hme1.samad.com.au)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind_s()=81 : Can't contact LDAP server




-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16-1-amd64-k8-smp
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)

Versions of packages sudo-ldap depends on:
ii  libc6                         2.3.6-7    GNU C Library: Shared libraries
ii  libldap2                      2.1.30-13  OpenLDAP libraries
ii  libpam-modules                0.79-3.1   Pluggable Authentication Modules f
ii  libpam0g                      0.79-3.1   Pluggable Authentication Modules l

sudo-ldap recommends no packages.

-- no debconf information



Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#368297; Package sudo-ldap. Full text and rfc822 format available.

Acknowledgement sent to Bdale Garbee <bdale@gag.com>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #10 received at 368297@bugs.debian.org (full text, mbox):

From: Bdale Garbee <bdale@gag.com>
To: Alexander Samad <alex@samad.com.au>, 368297@bugs.debian.org
Subject: Re: Bug#368297: sudo-ldap failes when you change uri to ldaps
Date: Sun, 21 May 2006 12:49:49 -0500
On Sun, 2006-05-21 at 19:25 +1000, Alexander Samad wrote:

> when I change this to 
> uri ldaps://hufpuf.lan1.hme1.samad.com.au
> it faills and I get with with debuging turned on

I don't use LDAP personally, and didn't see anything immediately obvious
on a quick perusal of the source.  If you or anyone else watching have
any idea why this is happening or how to fix it, feel free to chime in!

Bdale




Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. Full text and rfc822 format available.

Message #15 received at 368297@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Alexander Samad <alex@samad.com.au>, 368297@bugs.debian.org
Subject: Re: Bug#368297: sudo-ldap failes when you change uri to ldaps
Date: Sun, 21 May 2006 14:17:04 -0500
On Sun, May 21, 2006 at 07:25:38PM +1000, Alexander Samad wrote:
> Package: sudo-ldap
> Version: 1.6.8p12-4
> Severity: grave
> Justification: renders package unusable

> I have setup sudo-ldap to use the local ldap db. My /etc/ldap/ldap.conf
> has

> uri ldap://127.0.0.1

> when I change this to 

> uri ldaps://hufpuf.lan1.hme1.samad.com.au

> it faills and I get with with debuging turned on

> LDAP Config Summary
> ===================
> uri          ldaps://hufpuf.lan1.hme1.samad.com.au
> ldap_version 3
> sudoers_base ou=SUDOers,dc=samad,dc=com,dc=au
> binddn       (anonymous)
> bindpw       (anonymous)
> ssl          (no)
> ===================
> ldap_initialize(ld,ldaps://hufpuf.lan1.hme1.samad.com.au)
> ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
> ldap_simple_bind_s()=81 : Can't contact LDAP server

Why do you say that this is a sudo-ldap bug?  What tests have you done to
verify that this isn't a network/firewall bug or a libldap bug?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. Full text and rfc822 format available.

Acknowledgement sent to Alexander Samad <alex@samad.com.au>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. Full text and rfc822 format available.

Message #20 received at 368297@bugs.debian.org (full text, mbox):

From: Alexander Samad <alex@samad.com.au>
To: Steve Langasek <vorlon@debian.org>
Cc: Alexander Samad <alex@samad.com.au>, 368297@bugs.debian.org
Subject: Re: Bug#368297: sudo-ldap failes when you change uri to ldaps
Date: Mon, 22 May 2006 08:08:19 +1000
[Message part 1 (text/plain, inline)]
On Sun, May 21, 2006 at 02:17:04PM -0500, Steve Langasek wrote:
> On Sun, May 21, 2006 at 07:25:38PM +1000, Alexander Samad wrote:
> > Package: sudo-ldap
> > Version: 1.6.8p12-4
> > Severity: grave
> > Justification: renders package unusable
> 
> > I have setup sudo-ldap to use the local ldap db. My /etc/ldap/ldap.conf
> > has
> 
> > uri ldap://127.0.0.1
> 
> > when I change this to 
> 
> > uri ldaps://hufpuf.lan1.hme1.samad.com.au
> 
> > it faills and I get with with debuging turned on
> 
> > LDAP Config Summary
> > ===================
> > uri          ldaps://hufpuf.lan1.hme1.samad.com.au
> > ldap_version 3
> > sudoers_base ou=SUDOers,dc=samad,dc=com,dc=au
> > binddn       (anonymous)
> > bindpw       (anonymous)
> > ssl          (no)
> > ===================
> > ldap_initialize(ld,ldaps://hufpuf.lan1.hme1.samad.com.au)
> > ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
> > ldap_simple_bind_s()=81 : Can't contact LDAP server
> 
> Why do you say that this is a sudo-ldap bug?  What tests have you done to
> verify that this isn't a network/firewall bug or a libldap bug?

Hi

I configure a working system to start with.  The ldap server is on the
same machine, there are no iptable entries. libnss-ldap and libpam-ldap
work when I make the change from ldap://127.0.0.1 to
ldaps://hufpuf.lan1.hme1.samad.com.au

when I turn on logging from openldap I notice a connection being made
and then I notice the connectect is closed, no bind is attempted.

I can't rule out a libldap bug how can I test this ?

when I use ldapsearch with anon ldaps:// it works, but it links against
the 2.2 ldaplibraries.


> 
> -- 
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> vorlon@debian.org                                   http://www.debian.org/
> 
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. Full text and rfc822 format available.

Message #25 received at 368297@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Alexander Samad <alex@samad.com.au>, 368297@bugs.debian.org
Subject: Re: Bug#368297: sudo-ldap failes when you change uri to ldaps
Date: Sun, 21 May 2006 17:29:49 -0700
[Message part 1 (text/plain, inline)]
On Mon, May 22, 2006 at 08:08:19AM +1000, Alexander Samad wrote:
> > > it faills and I get with with debuging turned on

> > > LDAP Config Summary
> > > ===================
> > > uri          ldaps://hufpuf.lan1.hme1.samad.com.au
> > > ldap_version 3
> > > sudoers_base ou=SUDOers,dc=samad,dc=com,dc=au
> > > binddn       (anonymous)
> > > bindpw       (anonymous)
> > > ssl          (no)
> > > ===================
> > > ldap_initialize(ld,ldaps://hufpuf.lan1.hme1.samad.com.au)
> > > ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
> > > ldap_simple_bind_s()=81 : Can't contact LDAP server

> > Why do you say that this is a sudo-ldap bug?  What tests have you done to
> > verify that this isn't a network/firewall bug or a libldap bug?

> I configure a working system to start with.  The ldap server is on the
> same machine, there are no iptable entries. libnss-ldap and libpam-ldap
> work when I make the change from ldap://127.0.0.1 to
> ldaps://hufpuf.lan1.hme1.samad.com.au

> when I turn on logging from openldap I notice a connection being made
> and then I notice the connectect is closed, no bind is attempted.

> I can't rule out a libldap bug how can I test this ?

Well, it sounds to me like we can rule out a libldap problem based on this.

What I do notice is that you have an ldaps uri in the debugging output, but
it claims "ssl" is not enabled.  Is /etc/ldap/ldap.conf identical to
/etc/libnss-ldap.conf and /etc/libpam-ldap.conf?  Does negotiating an SSL
connection with this server require access to SSL certificates stored in
files which may not be accessible to sudo prior to assuming root perms?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. Full text and rfc822 format available.

Acknowledgement sent to Alexander Samad <alex@samad.com.au>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. Full text and rfc822 format available.

Message #30 received at 368297@bugs.debian.org (full text, mbox):

From: Alexander Samad <alex@samad.com.au>
To: Steve Langasek <vorlon@debian.org>
Cc: Alexander Samad <alex@samad.com.au>, 368297@bugs.debian.org
Subject: Re: Bug#368297: sudo-ldap failes when you change uri to ldaps
Date: Mon, 22 May 2006 11:21:53 +1000
[Message part 1 (text/plain, inline)]
On Sun, May 21, 2006 at 05:29:49PM -0700, Steve Langasek wrote:
> On Mon, May 22, 2006 at 08:08:19AM +1000, Alexander Samad wrote:
> > > > it faills and I get with with debuging turned on
> 
> > > > LDAP Config Summary
> > > > ===================
> > > > uri          ldaps://hufpuf.lan1.hme1.samad.com.au
> > > > ldap_version 3
> > > > sudoers_base ou=SUDOers,dc=samad,dc=com,dc=au
> > > > binddn       (anonymous)
> > > > bindpw       (anonymous)
> > > > ssl          (no)
> > > > ===================
> > > > ldap_initialize(ld,ldaps://hufpuf.lan1.hme1.samad.com.au)
> > > > ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
> > > > ldap_simple_bind_s()=81 : Can't contact LDAP server
> 
> > > Why do you say that this is a sudo-ldap bug?  What tests have you done to
> > > verify that this isn't a network/firewall bug or a libldap bug?
> 
> > I configure a working system to start with.  The ldap server is on the
> > same machine, there are no iptable entries. libnss-ldap and libpam-ldap
> > work when I make the change from ldap://127.0.0.1 to
> > ldaps://hufpuf.lan1.hme1.samad.com.au
> 
> > when I turn on logging from openldap I notice a connection being made
> > and then I notice the connectect is closed, no bind is attempted.
> 
> > I can't rule out a libldap bug how can I test this ?
> 
> Well, it sounds to me like we can rule out a libldap problem based on this.
> 
> What I do notice is that you have an ldaps uri in the debugging output, but
> it claims "ssl" is not enabled.  Is /etc/ldap/ldap.conf identical to
> /etc/libnss-ldap.conf and /etc/libpam-ldap.conf?  Does negotiating an SSL
> connection with this server require access to SSL certificates stored in
> files which may not be accessible to sudo prior to assuming root perms?

I tried setting ssl=on in the /etc/ldap/ldap.conf file ( I downloaded
the source and had a look at ldap.c) but that made no difference, but I
did notice there was a section that was #ifdef out for ssl - it had
another type of bind function call.

When I changed the ssl=on the debug info was the same except that ssl
(yes) was printed out instead of ssl (no)

I have set it up so that client authentication is not need for ldaps.

> 
> -- 
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> vorlon@debian.org                                   http://www.debian.org/


[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. Full text and rfc822 format available.

Message #35 received at 368297@bugs.debian.org (full text, mbox):

From: Steve Langasek <vorlon@debian.org>
To: Alexander Samad <alex@samad.com.au>
Cc: 368297@bugs.debian.org
Subject: Re: Bug#368297: sudo-ldap failes when you change uri to ldaps
Date: Sun, 21 May 2006 18:39:56 -0700
[Message part 1 (text/plain, inline)]
On Mon, May 22, 2006 at 11:21:53AM +1000, Alexander Samad wrote:
> On Sun, May 21, 2006 at 05:29:49PM -0700, Steve Langasek wrote:

> I tried setting ssl=on in the /etc/ldap/ldap.conf file ( I downloaded
> the source and had a look at ldap.c) but that made no difference, but I
> did notice there was a section that was #ifdef out for ssl - it had
> another type of bind function call.

> When I changed the ssl=on the debug info was the same except that ssl
> (yes) was printed out instead of ssl (no)

Ok.

> I have set it up so that client authentication is not need for ldaps.

However, I believe that by default libldap requires access to a trusted copy
of the *server* certificate in order to establish an ldaps connection.  Is
it possible that pam_ldap and nss_ldap have access to *this* certificate,
while sudo-ldap does not?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. Full text and rfc822 format available.

Acknowledgement sent to Alexander Samad <alex@samad.com.au>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. Full text and rfc822 format available.

Message #40 received at 368297@bugs.debian.org (full text, mbox):

From: Alexander Samad <alex@samad.com.au>
To: Alexander Samad <alex@samad.com.au>
Cc: Steve Langasek <vorlon@debian.org>, 368297@bugs.debian.org
Subject: Re: Bug#368297: sudo-ldap failes when you change uri to ldaps
Date: Mon, 22 May 2006 11:38:17 +1000
[Message part 1 (text/plain, inline)]
On Mon, May 22, 2006 at 11:21:53AM +1000, Alexander Samad wrote:
> On Sun, May 21, 2006 at 05:29:49PM -0700, Steve Langasek wrote:
> > On Mon, May 22, 2006 at 08:08:19AM +1000, Alexander Samad wrote:
> > > > > it faills and I get with with debuging turned on
> > 
> > > > > LDAP Config Summary
> > > > > ===================
> > > > > uri          ldaps://hufpuf.lan1.hme1.samad.com.au
> > > > > ldap_version 3
> > > > > sudoers_base ou=SUDOers,dc=samad,dc=com,dc=au
> > > > > binddn       (anonymous)
> > > > > bindpw       (anonymous)
> > > > > ssl          (no)
> > > > > ===================
> > > > > ldap_initialize(ld,ldaps://hufpuf.lan1.hme1.samad.com.au)
> > > > > ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
> > > > > ldap_simple_bind_s()=81 : Can't contact LDAP server
> > 
> > > > Why do you say that this is a sudo-ldap bug?  What tests have you done to
> > > > verify that this isn't a network/firewall bug or a libldap bug?
> > 
> > > I configure a working system to start with.  The ldap server is on the
> > > same machine, there are no iptable entries. libnss-ldap and libpam-ldap
> > > work when I make the change from ldap://127.0.0.1 to
> > > ldaps://hufpuf.lan1.hme1.samad.com.au
> > 
> > > when I turn on logging from openldap I notice a connection being made
> > > and then I notice the connectect is closed, no bind is attempted.
> > 
> > > I can't rule out a libldap bug how can I test this ?
> > 
> > Well, it sounds to me like we can rule out a libldap problem based on this.
> > 
> > What I do notice is that you have an ldaps uri in the debugging output, but
> > it claims "ssl" is not enabled.  Is /etc/ldap/ldap.conf identical to
> > /etc/libnss-ldap.conf and /etc/libpam-ldap.conf?  Does negotiating an SSL
> > connection with this server require access to SSL certificates stored in
> > files which may not be accessible to sudo prior to assuming root perms?
> 
> I tried setting ssl=on in the /etc/ldap/ldap.conf file ( I downloaded
> the source and had a look at ldap.c) but that made no difference, but I
> did notice there was a section that was #ifdef out for ssl - it had
> another type of bind function call.
> 
> When I changed the ssl=on the debug info was the same except that ssl
> (yes) was printed out instead of ssl (no)
> 
> I have set it up so that client authentication is not need for ldaps.

I have just tried doing this test. from another machine I used
ldapsearch -v -H ldaps://hufpuf.lan1.hme1.samad.com.au uid=alex
This failed with similiar results in the slapd log file as when
sudo-ldap fails.

What I noticed was that the connection from the second machine was
actually using the ipv6 address to make the connection, but it would
just hang for some reason ? although I could make a ldap://[ipv6] with
no problem, not sure if this helps or confuses!

> 
> > 
> > -- 
> > Steve Langasek                   Give me a lever long enough and a Free OS
> > Debian Developer                   to set it on, and I can move the world.
> > vorlon@debian.org                                   http://www.debian.org/
> 
> 


[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. Full text and rfc822 format available.

Acknowledgement sent to Alexander Samad <alex@samad.com.au>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. Full text and rfc822 format available.

Message #45 received at 368297@bugs.debian.org (full text, mbox):

From: Alexander Samad <alex@samad.com.au>
To: Steve Langasek <vorlon@debian.org>
Cc: Alexander Samad <alex@samad.com.au>, 368297@bugs.debian.org
Subject: Re: Bug#368297: sudo-ldap failes when you change uri to ldaps
Date: Mon, 22 May 2006 11:49:56 +1000
On Sun, May 21, 2006 at 06:39:56PM -0700, Steve Langasek wrote:
> On Mon, May 22, 2006 at 11:21:53AM +1000, Alexander Samad wrote:
> > On Sun, May 21, 2006 at 05:29:49PM -0700, Steve Langasek wrote:
> 
> > I tried setting ssl=on in the /etc/ldap/ldap.conf file ( I downloaded
> > the source and had a look at ldap.c) but that made no difference, but I
> > did notice there was a section that was #ifdef out for ssl - it had
> > another type of bind function call.
> 
> > When I changed the ssl=on the debug info was the same except that ssl
> > (yes) was printed out instead of ssl (no)
> 
> Ok.
> 
> > I have set it up so that client authentication is not need for ldaps.
> 
> However, I believe that by default libldap requires access to a trusted copy
> of the *server* certificate in order to establish an ldaps connection.  Is
> it possible that pam_ldap and nss_ldap have access to *this* certificate,
> while sudo-ldap does not?
just tested coped /etc/ssl/certs/ca-certificates.crt to /tmp and all the
files in /etc/ssl/certs/ are readable

> 
> -- 
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> vorlon@debian.org                                   http://www.debian.org/





Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. Full text and rfc822 format available.

Acknowledgement sent to Michael Meskes <meskes@debian.org>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. Full text and rfc822 format available.

Message #50 received at 368297@bugs.debian.org (full text, mbox):

From: Michael Meskes <meskes@debian.org>
To: control@bugs.debian.org, 368297@bugs.debian.org
Subject: Downgrading
Date: Sat, 16 Sep 2006 19:32:36 +0200
severity 368297 important
thanks

I spend some time tracking down this issue and here's what I found:

- The only ssl option that has an effect is "start_tls", which should
  enable tls no matter ldap:// or ldaps:// is used.
- According to some stuff I read on the web the sudo guys prefer tls
  over ldap:// and even called ldaps usage deprecated.
- Authorization is always done via your normal pam setting. The
  sudo-ldap connection is only to retrieve the info about what a user
  may do.

I certainly was able to reproduce this bug, so I see no way to close it.
To find a fix we probably need someone with libldap knowledge to look at
the sources. But I see several ways to use the package. Or in other
words the package is not unusable. This is why I downgraded it.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!



Severity set to `important' from `grave' Request was from Michael Meskes <meskes@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. Full text and rfc822 format available.

Acknowledgement sent to Roberto C. Sánchez <roberto@connexer.com>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. Full text and rfc822 format available.

Message #57 received at 368297@bugs.debian.org (full text, mbox):

From: Roberto C. Sánchez <roberto@connexer.com>
To: 368297@bugs.debian.org
Cc: 368297-submitter@bugs.debian.org, pkg-openldap-devel@lists.alioth.debian.org
Subject: More information on sudo-ldap SSL(ldaps://) breakage
Date: Sat, 14 Apr 2007 22:42:37 -0400
[Message part 1 (text/plain, inline)]
After upgrading my Sarge workstation to Etch today, I decided to start
messing aroud with sudo-ldap.  I was a bit disappointed to find that it
did not work with ldaps:// schemes.  I did some digging and here is what
I have found.  I think that there are a combination of factors, which is
I why I have CC'd the pkg-openldap list.  There must be something going
here that I am just not seeing.

The scenario:

miami.connexer.com - the workstation
santiago.connexer.com - the LDAP server
localadmin - is a local account on miami
roberto - is an account served from LDAP on santiago

I followed the directions in /usr/share/doc/sudo-ldap/README.LDAP.gz.

I have the following lines in /etc/ldap/ldap.conf:

BASE    dc=connexer,dc=com
URI     ldaps://santiago.connexer.com
TLS_CACERT      /etc/ldap/cacert.pem

sudoers_base ou=Sudoers,dc=connexer,dc=com
sudoers_debug 2

Now, santiago's slapd is only accessible via SSL over port 636.  This is
done both by not allowing slapd to bind to the cleartext port and also
by shorewall rules.  I loaded the sudoers info slapd on santiago.  From
miami, I can see the data:

roberto@miami:~$ ldapsearch -x -LLL objectclass=sudoRole
dn: cn=defaults,ou=Sudoers,dc=connexer,dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here

dn: cn=root,ou=Sudoers,dc=connexer,dc=com
objectClass: top
objectClass: sudoRole
cn: root
sudoUser: root
sudoHost: ALL
sudoCommand: (ALL) ALL

dn: cn=roberto,ou=Sudoers,dc=connexer,dc=com
objectClass: top
objectClass: sudoRole
cn: roberto
sudoUser: roberto
sudoHost: ALL
sudoCommand: (ALL) ALL

Now, the sudoers file on miami has the following:

root    ALL=(ALL) ALL
localadmin      ALL=(ALL) ALL

The first step was to try invoke sudo from roberto's account:

roberto@miami:~$ sudo ls -a
LDAP Config Summary
===================
uri          ldaps://santiago.connexer.com
ldap_version 3
sudoers_base ou=Sudoers,dc=connexer,dc=com
binddn       (anonymous)
bindpw       (anonymous)
ssl          (no)
===================
ldap_initialize(ld,ldaps://santiago.connexer.com)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind_s()=81 : Can't contact LDAP server
Password:
Sorry, try again.
Password:
sudo: 1 incorrect password attempt

No joy.  Next, we try from localadmin's account:

roberto@miami:~$ su - localadmin
Password:
localadmin@miami:~$ sudo ls -a
LDAP Config Summary
===================
uri          ldaps://santiago.connexer.com
ldap_version 3
sudoers_base ou=Sudoers,dc=connexer,dc=com
binddn       (anonymous)
bindpw       (anonymous)
ssl          (no)
===================
ldap_initialize(ld,ldaps://santiago.connexer.com)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind_s()=81 : Can't contact LDAP server
.   .alias         .bash_logout   .bashrc  .lesshst  .Xauthority
..  .bash_history  .bash_profile  .cshrc   .ssh
localadmin@miami:~$ logout

It works, but the ldap_bind is still causing trouble.  Now, I have an
ldaps URI, but it still claims that ssl is not on.  I explicitly force
it on by adding the line "ssl on" to /etc/ldap/ldap.conf.  This is what
we see now for both accounts:

roberto@miami:~$ sudo ls -a
LDAP Config Summary
===================
uri          ldaps://santiago.connexer.com
ldap_version 3
sudoers_base ou=Sudoers,dc=connexer,dc=com
binddn       (anonymous)
bindpw       (anonymous)
ssl          on
===================
ldap_initialize(ld,ldaps://santiago.connexer.com)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind_s()=81 : Can't contact LDAP server
Password:
Sorry, try again.
Password:
sudo: 1 incorrect password attempt
roberto@miami:~$ su - localadmin
Password:
localadmin@miami:~$ sudo -k
LDAP Config Summary
===================
uri          ldaps://santiago.connexer.com
ldap_version 3
sudoers_base ou=Sudoers,dc=connexer,dc=com
binddn       (anonymous)
bindpw       (anonymous)
ssl          on
===================
ldap_initialize(ld,ldaps://santiago.connexer.com)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind_s()=81 : Can't contact LDAP server
localadmin@miami:~$ sudo ls -a
LDAP Config Summary
===================
uri          ldaps://santiago.connexer.com
ldap_version 3
sudoers_base ou=Sudoers,dc=connexer,dc=com
binddn       (anonymous)
bindpw       (anonymous)
ssl          on
===================
ldap_initialize(ld,ldaps://santiago.connexer.com)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind_s()=81 : Can't contact LDAP server
Password:
.   .alias         .bash_logout   .bashrc  .lesshst  .Xauthority
..  .bash_history  .bash_profile  .cshrc   .ssh
localadmin@miami:~$


So, it appears that nothing is really different here.  It turns out that
sudo's handling of TLS and SSL is somewhat broken (or brain dead).  I
applied the following patch to the sudo source package, rebuilt and
installed the new package:

----------8<---------->8----------
--- sudo-1.6.8p12.orig/ldap.c
+++ sudo-1.6.8p12/ldap.c
@@ -565,6 +565,9 @@
   if (!ldap_conf.port) ldap_conf.port=389;
   if (!ldap_conf.host) ldap_conf.host=estrdup("localhost");

+  if (ldap_conf.ssl && !strcasecmp(ldap_conf.ssl, "on")) {
+    ldap_conf.tls_checkpeer = LDAP_OPT_X_TLS_NEVER;
+  }

   if (ldap_conf.debug>1) {
     printf("LDAP Config Summary\n");
@@ -821,6 +824,8 @@

   /* Actually connect */

+  if (ldap_conf.debug>1) fprintf(stderr,
+         "ldap_simple_bind(ld,%s,%d)\n",ldap_conf.binddn,ldap_conf.bindpw);
   rc=ldap_simple_bind_s(ld,ldap_conf.binddn,ldap_conf.bindpw);
   if(rc){
     fprintf(stderr,"ldap_simple_bind_s()=%d : %s\n",
----------8<---------->8----------

Now, the check really needs to be smarter, so that the mere presence of
a directive to use port 636 or a URI starting with ldaps:// will make it
realize to use SSL instead of TLS.  But this is a quick and dirty hack.
Now, I have again removed the "ssl on" line from /etc/ldap/ldap.conf.
Here is what it looks like now for the two accounts:

roberto@miami:~$ sudo ls -a
LDAP Config Summary
===================
uri          ldaps://santiago.connexer.com
ldap_version 3
sudoers_base ou=Sudoers,dc=connexer,dc=com
binddn       (anonymous)
bindpw       (anonymous)
ssl          (no)
===================
ldap_initialize(ld,ldaps://santiago.connexer.com)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind(ld,(null),0)
ldap_simple_bind_s()=81 : Can't contact LDAP server
Password:
Sorry, try again.
Password:
sudo: 1 incorrect password attempt
roberto@miami:~$ su - localadmin
Password:
localadmin@miami:~$ sudo -k
LDAP Config Summary
===================
uri          ldaps://santiago.connexer.com
ldap_version 3
sudoers_base ou=Sudoers,dc=connexer,dc=com
binddn       (anonymous)
bindpw       (anonymous)
ssl          (no)
===================
ldap_initialize(ld,ldaps://santiago.connexer.com)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind(ld,(null),0)
ldap_simple_bind_s()=81 : Can't contact LDAP server
localadmin@miami:~$ sudo ls -a
LDAP Config Summary
===================
uri          ldaps://santiago.connexer.com
ldap_version 3
sudoers_base ou=Sudoers,dc=connexer,dc=com
binddn       (anonymous)
bindpw       (anonymous)
ssl          (no)
===================
ldap_initialize(ld,ldaps://santiago.connexer.com)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind(ld,(null),0)
ldap_simple_bind_s()=81 : Can't contact LDAP server
Password:
.   .alias         .bash_logout   .bashrc  .lesshst  .Xauthority
..  .bash_history  .bash_profile  .cshrc   .ssh
localadmin@miami:~$

Looks exactly the same as before.  roberto can't do anything and
localadmin succeeds, but gets an ldap_bind() warning.

Now, we add the "ssl on" line back into /etc/ldap/ldap.conf:

roberto@miami:~$ sudo ls -a
LDAP Config Summary
===================
uri          ldaps://santiago.connexer.com
ldap_version 3
sudoers_base ou=Sudoers,dc=connexer,dc=com
binddn       (anonymous)
bindpw       (anonymous)
ssl          on
===================
ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT,0x00)
ldap_initialize(ld,ldaps://santiago.connexer.com)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind(ld,(null),0)
ldap_simple_bind_s()=81 : Can't contact LDAP server
Password:
Sorry, try again.
Password:
sudo: 1 incorrect password attempt
roberto@miami:~$ su - localadmin
Password:
localadmin@miami:~$ sudo -k
LDAP Config Summary
===================
uri          ldaps://santiago.connexer.com
ldap_version 3
sudoers_base ou=Sudoers,dc=connexer,dc=com
binddn       (anonymous)
bindpw       (anonymous)
ssl          on
===================
ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT,0x00)
ldap_initialize(ld,ldaps://santiago.connexer.com)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind(ld,(null),0)
ldap_bind() ok
found:cn=defaults,ou=Sudoers,dc=connexer,dc=com
ldap search '(|(sudoUser=localadmin)(sudoUser=%localadmin)(sudoUser=%localadmin)(sudoUser=ALL))'
ldap search 'sudoUser=+*'
user_matches=0
host_matches=0
sudo_ldap_check(-1)=0x44
localadmin@miami:~$ sudo ls -a
LDAP Config Summary
===================
uri          ldaps://santiago.connexer.com
ldap_version 3
sudoers_base ou=Sudoers,dc=connexer,dc=com
binddn       (anonymous)
bindpw       (anonymous)
ssl          on
===================
ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT,0x00)
ldap_initialize(ld,ldaps://santiago.connexer.com)
ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03)
ldap_simple_bind(ld,(null),0)
ldap_bind() ok
found:cn=defaults,ou=Sudoers,dc=connexer,dc=com
ldap search '(|(sudoUser=localadmin)(sudoUser=%localadmin)(sudoUser=%localadmin)(sudoUser=ALL))'
ldap search 'sudoUser=+*'
user_matches=0
host_matches=0
sudo_ldap_check(0)=0x44
Password:
.   .alias         .bash_logout   .bashrc  .lesshst  .Xauthority
..  .bash_history  .bash_profile  .cshrc   .ssh
localadmin@miami:~$

Now things get interesting.  roberto still can't get anything, but when
localadmin tries to use sudo, his bind succeeds and sudo is able to
query the LDAP server.  Now, the strange thing is that if I add a local
account for roberto to /etc/passwd and /etc/shadow (with the same uid
and gid as is present in LDAP), then it works the same way for him.
Now, according to the LDAP documentation for sudo, it doesn't use
nsswitch at all.  But I am wondering if there might be some hidden
interaction there.  Either way, there is something about having a local
account that makes it able to bind to the LDAP server that otherwise
causes it fail.  Naturally, this makes things less desirable, since the
point of LDAP is to not have to create local accounts.

Of course, if I add the ignore_local_sudoers option in LDAP, then nobody
can do anything.

I have carefully looked through the source code to see if I can figure
out what is going on.  But as far as I can tell, everything important to
this is happening in sudo_ldap_check() in ldap.c, which is called only
one time from within sudo.c.  I can't find anything that implies that
there is some sort of additional check or another call being made that
might cause it to pull in a local account without an LDAP account.
There are a couple of calls to getuid() and while I am not a C library
guru, my understanding is to the calling application that function
transperently queries all the sources of account data available to the
system.

Hopefully someone can make a bit more sense of this.  

Regards,

-Roberto
-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
[signature.asc (application/pgp-signature, inline)]

Message sent on to Alexander Samad <alex@samad.com.au>:
Bug#368297. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. (Tue, 03 Mar 2009 01:09:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roberto C. Sánchez <roberto@connexer.com>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. (Tue, 03 Mar 2009 01:09:05 GMT) Full text and rfc822 format available.

Message #65 received at 368297@bugs.debian.org (full text, mbox):

From: Roberto C. Sánchez <roberto@connexer.com>
To: 368297@bugs.debian.org, 368297-submitter@bugs.debian.org, pkg-openldap-devel@lists.alioth.debian.org
Subject: Re: [Pkg-openldap-devel] More information on sudo-ldap SSL(ldaps://) breakage
Date: Mon, 2 Mar 2009 20:05:45 -0500
[Message part 1 (text/plain, inline)]
On Sat, Apr 14, 2007 at 10:42:37PM -0400, Roberto C. Sánchez wrote:
> After upgrading my Sarge workstation to Etch today, I decided to start
> messing aroud with sudo-ldap.  I was a bit disappointed to find that it
> did not work with ldaps:// schemes.  I did some digging and here is what
> I have found.  I think that there are a combination of factors, which is
> I why I have CC'd the pkg-openldap list.  There must be something going
> here that I am just not seeing.
> 

After upgrading my workstation and server to Lenny, I have found that my
described configuration works.  One thing to note, however, is that I
have rebuilt the Lenny OpenLDAP packages to link against OpenSSL,
instead of GnuTLS so that I can continue using ldaps:///.

So, I am not certain if the problem "fixed" itself in the Etch -> Lenny
upgrade or because of the GnuTLS -> OpenSSL switch.

In any event, someone who knows more about OpenLDAP should investigate
this deeper and/or close this bug.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
[signature.asc (application/pgp-signature, inline)]

Message sent on to Alexander Samad <alex@samad.com.au>:
Bug#368297. (Tue, 03 Mar 2009 01:09:07 GMT) Full text and rfc822 format available.

Merged 368297 545414. Request was from Rune Schjellerup Philosof <rune@philosof.dk> to control@bugs.debian.org. (Tue, 16 Feb 2010 09:27:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. (Tue, 16 Feb 2010 12:09:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Rune Schjellerup Philosof <rune@philosof.dk>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. (Tue, 16 Feb 2010 12:09:07 GMT) Full text and rfc822 format available.

Message #75 received at 368297@bugs.debian.org (full text, mbox):

From: Rune Schjellerup Philosof <rune@philosof.dk>
To: 368297@bugs.debian.org
Subject: Doesn't su also fail?
Date: Tue, 16 Feb 2010 12:54:22 +0100
Does su work while your sudo doesn't?
If both fail when using ssl the bug should probably be changed to
affecting glibc or libnss-ldap instead.
This is the case in ubuntu.

--
Rune




Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. (Thu, 29 Apr 2010 13:36:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Rune Schjellerup Philosof <rune@philosof.dk>:
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. (Thu, 29 Apr 2010 13:36:03 GMT) Full text and rfc822 format available.

Message #80 received at 368297@bugs.debian.org (full text, mbox):

From: Rune Schjellerup Philosof <rune@philosof.dk>
To: 368297@bugs.debian.org
Subject: bug probably caused by libgcrypt11 via gnutls
Date: Thu, 29 Apr 2010 15:23:51 +0200
See https://bugs.launchpad.net/debian/+source/sudo/+bug/423252
Apparently the bug is caused by libldap being compiled with gnutls which
uses libgcrypt

Explained in detail in comment #72
https://bugs.launchpad.net/debian/+source/sudo/+bug/423252/comments/72




Information forwarded to debian-bugs-dist@lists.debian.org, Bdale Garbee <bdale@gag.com>:
Bug#368297; Package sudo-ldap. (Thu, 07 Oct 2010 22:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to bdale@gag.com (Bdale Garbee):
Extra info received and forwarded to list. Copy sent to Bdale Garbee <bdale@gag.com>. (Thu, 07 Oct 2010 22:39:03 GMT) Full text and rfc822 format available.

Message #85 received at 368297@bugs.debian.org (full text, mbox):

From: bdale@gag.com (Bdale Garbee)
To: 368297@bugs.debian.org, control@bugs.debian.org
Subject: problem appears to lie in libldap
Date: Fri, 8 Oct 2010 07:37:18 +0900 (JST)
reassign 368297 libldap-2.4-2
thanks

I'm reassigning this but to libldap-2.4-2 since it now appears that the 
problem isn't actually in sudo, but in the interaction between libldap, 
gnutls, and gcrypt.

Bdale




Bug reassigned from package 'sudo-ldap' to 'libldap-2.4-2'. Request was from bdale@gag.com (Bdale Garbee) to control@bugs.debian.org. (Thu, 07 Oct 2010 22:39:11 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions sudo/1.7.2-2 and sudo/1.6.8p12-4. Request was from bdale@gag.com (Bdale Garbee) to control@bugs.debian.org. (Thu, 07 Oct 2010 22:39:12 GMT) Full text and rfc822 format available.

Added indication that 368297 affects release-notes Request was from David Adam <zanchey@ucc.gu.uwa.edu.au> to control@bugs.debian.org. (Mon, 06 Dec 2010 16:15:16 GMT) Full text and rfc822 format available.

Severity set to 'grave' from 'important' Request was from David Adam <zanchey@ucc.gu.uwa.edu.au> to control@bugs.debian.org. (Fri, 10 Dec 2010 03:51:09 GMT) Full text and rfc822 format available.

Severity set to 'important' from 'grave' Request was from Julien Cristau <jcristau@debian.org> to control@bugs.debian.org. (Sat, 25 Dec 2010 20:24:08 GMT) Full text and rfc822 format available.

Bug reassigned from package 'libldap-2.4-2' to 'libgcrypt11'. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Fri, 31 Dec 2010 22:09:05 GMT) Full text and rfc822 format available.

Forcibly Merged 368297 545414 566351. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Fri, 31 Dec 2010 22:09:05 GMT) Full text and rfc822 format available.

Added indication that 368297 affects libldap-2.4-2 Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Fri, 31 Dec 2010 22:09:07 GMT) Full text and rfc822 format available.

Forcibly Merged 368297 545414 566351 579647 601667. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Sat, 21 May 2011 20:21:05 GMT) Full text and rfc822 format available.

Removed indication that 368297 affects libldap-2.4-2 Added indication that 368297 affects libnss-ldap Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Sat, 21 May 2011 20:21:08 GMT) Full text and rfc822 format available.

Forcibly Merged 368297 545414 566351 579647 601667 628671. Request was from Nicolas François <nicolas.francois@centraliens.net> to control@bugs.debian.org. (Sat, 25 Jun 2011 10:42:13 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 16 Nov 2012 18:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 16 Nov 2012 18:27:06 GMT) Full text and rfc822 format available.

Message #112 received at 368297@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: Martijn van Brummelen <martijn@brumit.nl>, 658739@bugs.debian.org
Cc: 368297@bugs.debian.org
Subject: Re: Bug#658739: Patch from Ubuntu
Date: Fri, 16 Nov 2012 19:24:05 +0100
On 2012-11-16 Martijn van Brummelen <martijn@brumit.nl> wrote:
> I rebuild Wheezy's version of libgcrypt11_1.5.0-3 with the
> patch(no_global_init_during_thread_callbacks.diff)  from Ubuntu.
> I can confirm the new patched version of libgcrypt solves this problem,
> and I am able to use sudo again.

> Can someone review this patch and see if it would be a suitable solution
> to fix this problem?

> If needed I can prepare a NMU.

Hello,
The patch from Ubuntu breaks other stuff. See
<https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798>
and duplicates. Note that although this (LP 1013798) was fixed in
1.5.0-3ubuntu2 the patch had to be pulled again in 1.5.0-3ubuntu2.1
because of
<https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1076906>

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 30 Nov 2012 13:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Martijn van Brummelen" <martijn@brumit.nl>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 30 Nov 2012 13:57:03 GMT) Full text and rfc822 format available.

Message #117 received at 368297@bugs.debian.org (full text, mbox):

From: "Martijn van Brummelen" <martijn@brumit.nl>
To: "Andreas Metzler" <ametzler@downhill.at.eu.org>
Cc: 658739@bugs.debian.org, 368297@bugs.debian.org
Subject: Re: Bug#658739: Patch from Ubuntu
Date: Fri, 30 Nov 2012 14:50:02 +0100
> Hello,
> The patch from Ubuntu breaks other stuff. See
> <https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798>
> and duplicates. Note that although this (LP 1013798) was fixed in
> 1.5.0-3ubuntu2 the patch had to be pulled again in 1.5.0-3ubuntu2.1
> because of
> <https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1076906>
How about suggestion nr 22 suggested on
https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/926350
Will that do any harm? I can confirm it makes sudo work again. Will test
some more to see if it breaks anything else.

Regards,
martijn van brummelen




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Sun, 02 Dec 2012 09:45:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Metzler <ametzler@downhill.at.eu.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Sun, 02 Dec 2012 09:45:12 GMT) Full text and rfc822 format available.

Message #122 received at 368297@bugs.debian.org (full text, mbox):

From: Andreas Metzler <ametzler@downhill.at.eu.org>
To: Martijn van Brummelen <martijn@brumit.nl>, 658739@bugs.debian.org, 368297@bugs.debian.org
Subject: Re: Bug#658739: Patch from Ubuntu
Date: Sun, 2 Dec 2012 09:11:18 +0100
On 2012-11-30 Martijn van Brummelen <martijn@brumit.nl> wrote:
> > Hello,
> > The patch from Ubuntu breaks other stuff. See
> > <https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1013798>
> > and duplicates. Note that although this (LP 1013798) was fixed in
> > 1.5.0-3ubuntu2 the patch had to be pulled again in 1.5.0-3ubuntu2.1
> > because of
> > <https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/1076906>
> How about suggestion nr 22 suggested on
> https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/926350

We cannot switch to a GPLv2-incompatible gnutls stack on Debian
currently.[1]

cu andreas

[1] We will need to do this for wheezy + 1, because Debian
does not have the manpower to fork GnuTLS 2.x. But that is a different
discussion.



Added tag(s) d-i and patch. Request was from Andreas Metzler <ametzler@debian.org> to control@bugs.debian.org. (Tue, 22 Jan 2013 18:18:11 GMT) Full text and rfc822 format available.

Merged 368297 545414 566351 579647 601667 628671 658896 Request was from Andreas Metzler <ametzler@debian.org> to control@bugs.debian.org. (Tue, 22 Jan 2013 18:18:14 GMT) Full text and rfc822 format available.

Severity set to 'serious' from 'normal' Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Wed, 23 Jan 2013 12:27:08 GMT) Full text and rfc822 format available.

Merged 368297 545414 566351 579647 601667 628671 658896 Request was from Andreas Metzler <ametzler@debian.org> to control@bugs.debian.org. (Wed, 23 Jan 2013 17:54:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Thu, 24 Jan 2013 23:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 24 Jan 2013 23:48:03 GMT) Full text and rfc822 format available.

Message #135 received at 368297@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: Andreas Metzler <ametzler@downhill.at.eu.org>, adam.stokes@canonical.com
Cc: 368297@bugs.debian.org, 545414@bugs.debian.org, 566351@bugs.debian.org, 579647@bugs.debian.org, 601667@bugs.debian.org, 628671@bugs.debian.org, 658896@bugs.debian.org, pkg-openldap-devel@lists.alioth.debian.org, pkg-gnutls-maint@lists.alioth.debian.org, control@bugs.debian.org
Subject: [PATCH] Fix dropping privileges issue on setuid programs on systems with PAM/LDAP and GnuTLS/libgcrypt
Date: Fri, 25 Jan 2013 00:44:21 +0100
[Message part 1 (text/plain, inline)]
reassign 368297 libldap-2.4 2.4.31-1
thanks

Hi!


I have been digging on this issue and I found the ultimate cause of this
problem.


When sudo/su/passwd/<insert-any-setuid-program-that-calls-getpwent()> on
a system configured with PAM/LDAPs it chains into libldap, which uses
GnuTLS/libgcrypt to manage the TLS channel.


The problem is that when OpenLDAP calls gnutls_global_init(), this
function does nothing because OpenLDAP had previously already
initialized libgcrypt at some point on the stack (probably by mistake).

So, gnutls_global_init() checks that some basic initialization of
libgcrypt was already done and skips completely any action.

The problem is that gnutls_global_init() is supposed to set the flag
GCRYCTL_DISABLE_SECMEM which disables both the use of secure memory
*and* the "feature" of dropping privileges that libgcrypt has. [1]

So, what is happening is that the initialization of libgcrypt is not
being done as expected.

I cooked a very small patch that, just after calling
gnutls_global_init() checks if the initialization was successful, and if
was not, then it sets this flag (DISABLE_SECMEM)

I understand that (perhaps) the right fix could be to patch GnuTLS to
check for INITIALIZATION_FINISHED instead of ANY_INITIALIZATION. But
there are two problems with this:

 * One is that this could introduce some regression or bug on some
program that could be (wrongly) relying on this "feature" of GnuTLS.
Keep in mind that this code has been there since the beginning of the
project (I was blaming the git repository)


* The second problem is that GnutTLS (upstream) completely dropped the
support for libgcrypt (they even removed the code). So IMHO it don't
makes sense to fix GnuTLS at this point. For Jessie, GnuTLS should
switch to nettle. And OpenLDAP will have to switch to another crypto
library other than libgcrypt, or will have to patch the file
libraries/libldap/tls_g.c to stop using any GnuTLS code.


So, for the moment (Wheezy) I think the best approach to solve this bug
is to apply the small patch for OpenLDAP that I'm attaching.
It is the less intrusive approach to fix this bug. It don't needs to
touch anything on GnuTLS or libgcrypt. It is really fixing the problem
where is: OpenLDAP is not setting DISABLE_SECMEM when initializing
libgcrypt.

The approach taken by Ubuntu, to patch libgcrypt (LP: #423252), already
caused some regressions (LP: #1013798)


If someone wants to try it, I have uploaded the debs (AMD64) and the
sources to this URL:

http://ftp.neutrino.es/debian/OpenLDAP/


I tested that with this small patch the problem goes completely away.

Example of test:
----------------
1) Install current libldap-2.4-2 from Wheezy and test sudo:
root ~ # apt-get install --reinstall libldap-2.4-2=2.4.31-1

clopez ~ $ sudo whoami
[sudo] password for clopez:
sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted
sudo: unable to open /var/lib/sudo/clopez/8: Operation not permitted
sudo: unable to set supplementary group IDs: Operation not permitted
sudo: unable to execute /usr/bin/whoami: Operation not permitted


2) Install fixed libldap-2.4-2 and test sudo:
root ~ # wget
http://ftp.neutrino.es/debian/OpenLDAP/libldap-2.4-2_2.4.31-1.1_amd64.deb
root ~ # dpkg -i libldap-2.4-2_2.4.31-1.1_amd64.deb


clopez ~ $ sudo whoami
[sudo] password for clopez:
root
-------------

Therefore I'm reassigning this bug to libldap-2.4 (src:OpenLDAP)

Attached is also a debdiff for src:OpenLDAP


Read the comments inside the patch for further information.


I'm CC'ing libgcrypt/OpenLDAP/GnuTLS maintainers and will be later
reporting on Ubuntu's LP this.



Regards!
--------

[1]
http://lists.debian.org/debian-devel/2010/03/msg00298.html
https://bugs.g10code.com/gnupg/issue1181
[debdiff_openldap_fix-dropping-privileges-by-libgcrypt-secmem.debdiff (text/plain, attachment)]
[fix-dropping-privileges-by-libgcrypt-secmem.diff (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, attachment)]

Bug reassigned from package 'libgcrypt11' to 'libldap-2.4'. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Thu, 24 Jan 2013 23:48:18 GMT) Full text and rfc822 format available.

No longer marked as found in versions libgcrypt11/1.4.4-6. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Thu, 24 Jan 2013 23:48:20 GMT) Full text and rfc822 format available.

Marked as found in versions 2.4.31-1. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Thu, 24 Jan 2013 23:48:23 GMT) Full text and rfc822 format available.

Bug reassigned from package 'libldap-2.4' to 'libldap-2.4-2'. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Fri, 25 Jan 2013 03:09:09 GMT) Full text and rfc822 format available.

No longer marked as found in versions 2.4.31-1. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Fri, 25 Jan 2013 03:09:12 GMT) Full text and rfc822 format available.

Marked as found in versions openldap/2.4.31-1. Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Fri, 25 Jan 2013 03:09:15 GMT) Full text and rfc822 format available.

Unset Bug forwarded-to-address Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Fri, 25 Jan 2013 04:27:03 GMT) Full text and rfc822 format available.

Merged 368297 545414 566351 579647 601667 628671 658739 658896 Request was from Carlos Alberto Lopez Perez <clopez@igalia.com> to control@bugs.debian.org. (Tue, 05 Feb 2013 03:24:14 GMT) Full text and rfc822 format available.

Removed tag(s) d-i. Request was from Adam D. Barratt <adam@adam-barratt.org.uk> to control@bugs.debian.org. (Wed, 20 Feb 2013 11:33:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>:
Bug#368297; Package libldap-2.4-2. (Sat, 02 Mar 2013 17:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thijs Kinkhorst <thijs@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>. (Sat, 02 Mar 2013 17:03:03 GMT) Full text and rfc822 format available.

Message #158 received at 368297@bugs.debian.org (full text, mbox):

From: Thijs Kinkhorst <thijs@debian.org>
To: 368297@bugs.debian.org
Cc: Carlos Alberto Lopez Perez <clopez@igalia.com>
Subject: Re: [PATCH] Fix dropping privileges issue on setuid programs on systems with PAM/LDAP and GnuTLS/libgcrypt
Date: Sat, 2 Mar 2013 17:58:39 +0100
[Message part 1 (text/plain, inline)]
> So, for the moment (Wheezy) I think the best approach to solve this bug
> is to apply the small patch for OpenLDAP that I'm attaching.
> It is the less intrusive approach to fix this bug. It don't needs to
> touch anything on GnuTLS or libgcrypt. It is really fixing the problem
> where is: OpenLDAP is not setting DISABLE_SECMEM when initializing
> libgcrypt.

So, is there a reason not to go with Carlos' patch for openldap?


Cheers,
Thijs
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>:
Bug#368297; Package libldap-2.4-2. (Thu, 21 Mar 2013 21:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jack Bates <8it1g1@nottheoilrig.com>:
Extra info received and forwarded to list. Copy sent to Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>. (Thu, 21 Mar 2013 21:27:04 GMT) Full text and rfc822 format available.

Message #163 received at 368297@bugs.debian.org (full text, mbox):

From: Jack Bates <8it1g1@nottheoilrig.com>
To: 368297@bugs.debian.org
Subject: Initializing Libgcrypt
Date: Thu, 21 Mar 2013 14:18:35 -0700
I contributed a fix for the regression caused by the solution in Ubuntu 
[1]. The Python wrapper for the GnuTLS library doesn't initialize 
Libgcrypt properly.

One addition to Carlos' analysis:

> The problem is that when OpenLDAP calls gnutls_global_init(), this
> function does nothing because OpenLDAP had previously already
> initialized libgcrypt at some point on the stack (probably by
> mistake).

My understanding of Howard Chu in LP: #423252 comment #72 [2] is that 
OpenLDAP doesn't initialize Libgcrypt (it doesn't invoke 
gcry_check_version which the manual states must be invoked before any 
other function in the library, and which is correctly invoked by 
gnutls_global_init). OpenLDAP is required to initialize Libgcrypt's 
thread callbacks with GCRYCTL_SET_THREAD_CBS and prior to Libgcrypt 
version 1.3.X GCRYCTL_SET_THREAD_CBS didn't invoke global_init. So the 
solution in Ubuntu [3] is consistent with the Libgcrypt manual 
(gcry_check_version must be invoked before any other function in the 
library, with the exception of the GCRYCTL_SET_THREAD_CBS command) and 
with the original behavior of the library.

  [1] 
https://code.launchpad.net/~nottheoilrig/ubuntu/quantal/python-gnutls/fix-for-1013798/+merge/154767
  [2] https://bugs.launchpad.net/bugs/423252
  [3] https://launchpadlibrarian.net/45701569/dif1.txt



Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>:
Bug#368297; Package libldap-2.4-2. (Wed, 03 Apr 2013 14:12:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jack Bates <8it1g1@nottheoilrig.com>:
Extra info received and forwarded to list. Copy sent to Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>. (Wed, 03 Apr 2013 14:12:04 GMT) Full text and rfc822 format available.

Message #168 received at 368297@bugs.debian.org (full text, mbox):

From: Jack Bates <8it1g1@nottheoilrig.com>
To: 368297@bugs.debian.org
Subject: Blog post about Libgcrypt issue
Date: Wed, 03 Apr 2013 07:09:47 -0700
Hi, here is a blog post about this issue:

http://jdbates.blogspot.ca/2013/04/its-crazy-how-much-time-and-effort-one.html



Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>:
Bug#368297; Package libldap-2.4-2. (Wed, 03 Apr 2013 17:45:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>. (Wed, 03 Apr 2013 17:45:09 GMT) Full text and rfc822 format available.

Message #173 received at 368297@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: Jack Bates <8it1g1@nottheoilrig.com>, Andreas Metzler <ametzler@debian.org>
Cc: 368297@bugs.debian.org
Subject: About the libgcrypt and OpenLDAP issue
Date: Wed, 03 Apr 2013 19:43:19 +0200
[Message part 1 (text/plain, inline)]
On 03/04/13 16:09, Jack Bates wrote:
> Hi, here is a blog post about this issue:
> 
> http://jdbates.blogspot.ca/2013/04/its-crazy-how-much-time-and-effort-one.html
> 

Really very interesting stuff. Thanks for sharing


Now I'm convinced that the right fix for this is to revert upstream
d769529a71ccda4e833f919f3c5693d25b005ff0 [1] commit on libgcrypt like
Ubuntu did.

The Regression introduced on python-gnutls by such reversion was already
fixed on Ubuntu with another patch (see LP:#1013798 [2]) and they have
been running with the patch for some time without more problems (AFAIK)
so I think that we can assume that there are no more regressions.


Therefore I think we should reassign this bug back to libgcrypt11. Fix
it with a patch that reverts d769529a71ccda4e833f919f3c5693d25b005ff0
[1] and then fill another RC bug for python-gnutls asking for applying
the same patch that Ubuntu applied (see LP:#1013798 [2])

Andreas.. what do you think? looks this like the way to go for you?

Furthermore libgcrypt upstream seems to be ok with this change, isn't
it? [3]



Regards!
--------


[1]
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commitdiff;h=d769529a71ccda4e833f919f3c5693d25b005ff0
[2] https://bugs.launchpad.net/bugs/1013798
[3] http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>:
Bug#368297; Package libldap-2.4-2. (Wed, 03 Apr 2013 18:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jack Bates <8it1g1@nottheoilrig.com>:
Extra info received and forwarded to list. Copy sent to Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>. (Wed, 03 Apr 2013 18:21:05 GMT) Full text and rfc822 format available.

Message #178 received at 368297@bugs.debian.org (full text, mbox):

From: Jack Bates <8it1g1@nottheoilrig.com>
To: Carlos Alberto Lopez Perez <clopez@igalia.com>
Cc: Andreas Metzler <ametzler@debian.org>, 368297@bugs.debian.org
Subject: Re: About the libgcrypt and OpenLDAP issue
Date: Wed, 03 Apr 2013 11:17:05 -0700
On 03/04/13 10:43 AM, Carlos Alberto Lopez Perez wrote:
> Furthermore libgcrypt upstream seems to be ok with this change, isn't
> it? [3]

Thanks for finding this upstream thread Carlos! And for your work 
earlier where you spotted the 2005 upstream commit.

> [3] http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198



Information forwarded to debian-bugs-dist@lists.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>:
Bug#368297; Package libldap-2.4-2. (Tue, 09 Apr 2013 16:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon Fondrie-Teitler <simonft@riseup.net>:
Extra info received and forwarded to list. Copy sent to Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>. (Tue, 09 Apr 2013 16:21:03 GMT) Full text and rfc822 format available.

Message #183 received at 368297@bugs.debian.org (full text, mbox):

From: Simon Fondrie-Teitler <simonft@riseup.net>
To: Carlos Alberto Lopez Perez <clopez@igalia.com>
Cc: 368297@bugs.debian.org
Subject: Re: About the libgcrypt and OpenLDAP issue
Date: Tue, 09 Apr 2013 11:13:51 -0500
Hi, 

Carlos Alberto Lopez Perez <clopez@igalia.com> writes:
> Now I'm convinced that the right fix for this is to revert upstream
> d769529a71ccda4e833f919f3c5693d25b005ff0 [1] commit on libgcrypt like
> Ubuntu did.
>
> The Regression introduced on python-gnutls by such reversion was already
> fixed on Ubuntu with another patch (see LP:#1013798 [2]) and they have
> been running with the patch for some time without more problems (AFAIK)
> so I think that we can assume that there are no more regressions.
>
> Therefore I think we should reassign this bug back to libgcrypt11. Fix
> it with a patch that reverts d769529a71ccda4e833f919f3c5693d25b005ff0
> [1] and then fill another RC bug for python-gnutls asking for applying
> the same patch that Ubuntu applied (see LP:#1013798 [2])

At work we are running into this problem while testing wheezy. setuid
programs were failing when authenticating over ldap. I've tested a patch
to libgcrypt11 reverting d769529a71ccda4e833f919f3c5693d25b005ff0 and it
fixes the problem for us, with no obvious regressions. If you want me to
do any more testing I can do so.

Is it possible to get this fixed for the wheezy release? It would
greatly smooth our rollout of wheezy.

Thanks to all for your work on this. 




Bug reassigned from package 'libldap-2.4-2' to 'libgcrypt11'. Request was from Michael Gilbert <mgilbert@debian.org> to control@bugs.debian.org. (Sun, 14 Apr 2013 18:39:04 GMT) Full text and rfc822 format available.

No longer marked as found in versions openldap/2.4.31-1. Request was from Michael Gilbert <mgilbert@debian.org> to control@bugs.debian.org. (Sun, 14 Apr 2013 18:39:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Tue, 16 Apr 2013 18:39:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Tue, 16 Apr 2013 18:39:09 GMT) Full text and rfc822 format available.

Message #192 received at 368297@bugs.debian.org (full text, mbox):

From: "Adam D. Barratt" <adam@adam-barratt.org.uk>
To: Simon Fondrie-Teitler <simonft@riseup.net>, 368297@bugs.debian.org
Cc: Carlos Alberto Lopez Perez <clopez@igalia.com>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Tue, 16 Apr 2013 19:37:31 +0100
On Tue, 2013-04-09 at 11:13 -0500, Simon Fondrie-Teitler wrote:
> Carlos Alberto Lopez Perez <clopez@igalia.com> writes:
> > Therefore I think we should reassign this bug back to libgcrypt11. Fix
> > it with a patch that reverts d769529a71ccda4e833f919f3c5693d25b005ff0
> > [1] and then fill another RC bug for python-gnutls asking for applying
> > the same patch that Ubuntu applied (see LP:#1013798 [2])
> 
> At work we are running into this problem while testing wheezy. setuid
> programs were failing when authenticating over ldap. I've tested a patch
> to libgcrypt11 reverting d769529a71ccda4e833f919f3c5693d25b005ff0 and it
> fixes the problem for us, with no obvious regressions. If you want me to
> do any more testing I can do so.
> 
> Is it possible to get this fixed for the wheezy release? It would
> greatly smooth our rollout of wheezy.

libgcrypt maintainers - any thoughts on this?

Regards,

Adam




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Thu, 18 Apr 2013 17:06:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 18 Apr 2013 17:06:04 GMT) Full text and rfc822 format available.

Message #197 received at 368297@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: "Adam D. Barratt" <adam@adam-barratt.org.uk>
Cc: 368297@bugs.debian.org, Simon Fondrie-Teitler <simonft@riseup.net>, Carlos Alberto Lopez Perez <clopez@igalia.com>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Thu, 18 Apr 2013 18:58:02 +0200
On Tue, 16 Apr 2013 20:37, adam@adam-barratt.org.uk said:

> libgcrypt maintainers - any thoughts on this?

Did anything change since my comments from 2010?

OpenLDAP needs to get it right and it would even be better if all
applications would set up a their policy regarding their demand for
private key protection.  For instacne by setting up a custom memory
handler.

My current problem with OpenLDAP is that it can't be used anymore with
GnuTLS 3 because the OpenSSL emulation switched to GPLv3+ and thus no
software with GPLv2only parts is able to use OpenLDAP.  The
straightforward solution would be to change OpenLDAP to use the native
GNUTLS API and while at it also fix the libgcrypt initialization.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Thu, 18 Apr 2013 18:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 18 Apr 2013 18:27:04 GMT) Full text and rfc822 format available.

Message #202 received at 368297@bugs.debian.org (full text, mbox):

From: "Adam D. Barratt" <adam@adam-barratt.org.uk>
To: Werner Koch <wk@gnupg.org>, 368297@bugs.debian.org
Cc: Simon Fondrie-Teitler <simonft@riseup.net>, Carlos Alberto Lopez Perez <clopez@igalia.com>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Thu, 18 Apr 2013 19:24:41 +0100
On Thu, 2013-04-18 at 18:58 +0200, Werner Koch wrote:
> On Tue, 16 Apr 2013 20:37, adam@adam-barratt.org.uk said:
> 
> > libgcrypt maintainers - any thoughts on this?
> 
> Did anything change since my comments from 2010?
> 
> OpenLDAP needs to get it right and it would even be better if all
> applications would set up a their policy regarding their demand for
> private key protection.  For instacne by setting up a custom memory
> handler.
> 
> My current problem with OpenLDAP is that it can't be used anymore with
> GnuTLS 3 because the OpenSSL emulation switched to GPLv3+

GnuTLS 3 isn't particularly relevant to getting this RC bug fixed in
wheezy, given that wheezy will be shipping with 2.12.

> The straightforward solution would be to change OpenLDAP to use the 
> native GNUTLS API and while at it also fix the libgcrypt
> initialization.

In less than two weeks, without introducing any new bugs?

The realistic alternatives as far as I can see currently are that the
suggested fix gets applied or this bug remains unfixed for wheezy.

Opinions that help towards a constructive resolution appreciated.

Regards,

Adam




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Thu, 18 Apr 2013 18:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 18 Apr 2013 18:45:04 GMT) Full text and rfc822 format available.

Message #207 received at 368297@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: "Adam D. Barratt" <adam@adam-barratt.org.uk>
Cc: Werner Koch <wk@gnupg.org>, 368297@bugs.debian.org, Simon Fondrie-Teitler <simonft@riseup.net>, Howard Chu <hyc@symas.com>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Thu, 18 Apr 2013 20:40:44 +0200
[Message part 1 (text/plain, inline)]
On 18/04/13 20:24, Adam D. Barratt wrote:
> On Thu, 2013-04-18 at 18:58 +0200, Werner Koch wrote:
>> On Tue, 16 Apr 2013 20:37, adam@adam-barratt.org.uk said:
>>
>>> libgcrypt maintainers - any thoughts on this?
>>
>> Did anything change since my comments from 2010?
>>
>> OpenLDAP needs to get it right and it would even be better if all
>> applications would set up a their policy regarding their demand for
>> private key protection.  For instacne by setting up a custom memory
>> handler.
>>

Howard Chu (CC'ed) (main OpenLDAP developer) thinks the other way. Check:

http://bugs.debian.org/658896#115

>> My current problem with OpenLDAP is that it can't be used anymore with
>> GnuTLS 3 because the OpenSSL emulation switched to GPLv3+
> 
> GnuTLS 3 isn't particularly relevant to getting this RC bug fixed in
> wheezy, given that wheezy will be shipping with 2.12.
> 
>> The straightforward solution would be to change OpenLDAP to use the 
>> native GNUTLS API and while at it also fix the libgcrypt
>> initialization.
> 
> In less than two weeks, without introducing any new bugs?
> 
> The realistic alternatives as far as I can see currently are that the
> suggested fix gets applied or this bug remains unfixed for wheezy.
> 
> Opinions that help towards a constructive resolution appreciated.
> 
> Regards,
> 
> Adam
> 
> 

I see two options to get this fixed for Wheezy:

[Option 1] -- Do the same that Ubuntu did. That is:

1.a) Patch libgcrypt to revert commit
     d769529a71ccda4e833f919f3c5693d25b005ff0

1.b) Patch python-gnutls to fix the regression that 1.a) will introduce.
     Check: http://bugs.debian.org/368297#173


[Option 2] -- Patch OpenLDAP to set the flag GCRYCTL_DISABLE_SECMEM if
GCRYCTL_INITIALIZATION_FINISHED is false. This is the patch I previously
proposed at http://bugs.debian.org/368297#135



Any of the two options will fix the problem. Which one is better? You bet


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Thu, 18 Apr 2013 22:00:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 18 Apr 2013 22:00:05 GMT) Full text and rfc822 format available.

Message #212 received at 368297@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Carlos Alberto Lopez Perez <clopez@igalia.com>
Cc: "Adam D. Barratt" <adam@adam-barratt.org.uk>, 368297@bugs.debian.org, Simon Fondrie-Teitler <simonft@riseup.net>, Howard Chu <hyc@symas.com>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Thu, 18 Apr 2013 23:53:08 +0200
On Thu, 18 Apr 2013 20:40, clopez@igalia.com said:

> I see two options to get this fixed for Wheezy:
>
> [Option 1] -- Do the same that Ubuntu did. That is:
>
> 1.a) Patch libgcrypt to revert commit
>      d769529a71ccda4e833f919f3c5693d25b005ff0

Urgs.  That is a short sighted fix.

> [Option 2] -- Patch OpenLDAP to set the flag GCRYCTL_DISABLE_SECMEM if
> GCRYCTL_INITIALIZATION_FINISHED is false. This is the patch I previously
> proposed at http://bugs.debian.org/368297#135

That is the most correct solution.  Any application (not library) which
wants to use that mlock protected memory (aka secure memory) needs to
make sure that libgcrypt has been initialized correctly.  Thus if the
application does not do that and a library wants to to its own thing,
that library should do it in the above way.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Thu, 18 Apr 2013 22:06:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Thu, 18 Apr 2013 22:06:04 GMT) Full text and rfc822 format available.

Message #217 received at 368297@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: "Adam D. Barratt" <adam@adam-barratt.org.uk>
Cc: 368297@bugs.debian.org, Simon Fondrie-Teitler <simonft@riseup.net>, Carlos Alberto Lopez Perez <clopez@igalia.com>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Thu, 18 Apr 2013 23:58:58 +0200
On Thu, 18 Apr 2013 20:24, adam@adam-barratt.org.uk said:

> GnuTLS 3 isn't particularly relevant to getting this RC bug fixed in
> wheezy, given that wheezy will be shipping with 2.12.

It also ships 3.0 (libgnutls28) which then sometimes leads tp processes
linking two different versions of GNUTLS.  Usually this works, but it is
not a pretty thing and might be the cause for other trouble later.

> In less than two weeks, without introducing any new bugs?

[Why two weeks?]

> Opinions that help towards a constructive resolution appreciated.

I did this 3 years ago and would have appreciated if that persisting
problem had been raised again at gcrypt-devel.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 00:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Gilbert <mgilbert@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 00:57:04 GMT) Full text and rfc822 format available.

Message #222 received at 368297@bugs.debian.org (full text, mbox):

From: Michael Gilbert <mgilbert@debian.org>
To: 368297@bugs.debian.org, wk@gnupg.org
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Thu, 18 Apr 2013 20:52:43 -0400
>> 1.a) Patch libgcrypt to revert commit
>>      d769529a71ccda4e833f919f3c5693d25b005ff0
>
> Urgs.  That is a short sighted fix.

That seems to be the solution the rest of the open source community is
converging toward.  Short sighted is an odd categorization since it
seems to have taken 8 years to come to this conclusion.

Maybe some of the blogs on the issue and other comments in this bug
log would be of useful to understand why.  For example:
http://jdbates.blogspot.ca/2013/04/its-crazy-how-much-time-and-effort-one.html

>> In less than two weeks, without introducing any new bugs?
>
> [Why two weeks?]

That is when wheezy get released.

Best wishes,
Mike



Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 08:06:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Howard Chu <hyc@symas.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 08:06:04 GMT) Full text and rfc822 format available.

Message #227 received at 368297@bugs.debian.org (full text, mbox):

From: Howard Chu <hyc@symas.com>
To: Werner Koch <wk@gnupg.org>, Carlos Alberto Lopez Perez <clopez@igalia.com>
Cc: "Adam D. Barratt" <adam@adam-barratt.org.uk>, 368297@bugs.debian.org, Simon Fondrie-Teitler <simonft@riseup.net>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 00:22:24 -0700
Werner Koch wrote:
> On Thu, 18 Apr 2013 20:40, clopez@igalia.com said:
>
>> I see two options to get this fixed for Wheezy:
>>
>> [Option 1] -- Do the same that Ubuntu did. That is:
>>
>> 1.a) Patch libgcrypt to revert commit
>>       d769529a71ccda4e833f919f3c5693d25b005ff0
>
> Urgs.  That is a short sighted fix.
>
>> [Option 2] -- Patch OpenLDAP to set the flag GCRYCTL_DISABLE_SECMEM if
>> GCRYCTL_INITIALIZATION_FINISHED is false. This is the patch I previously
>> proposed at http://bugs.debian.org/368297#135
>
> That is the most correct solution.

Excuse me? By what measure is this correct? Certainly not by any published 
official documentation.

>  Any application (not library) which
> wants to use that mlock protected memory (aka secure memory) needs to
> make sure that libgcrypt has been initialized correctly.  Thus if the
> application does not do that and a library wants to to its own thing,
> that library should do it in the above way.

The OpenLDAP library doesn't want one thing or another at all. It simply is 
expected to use GnuTLS on Debian and it initializes it as documented.

Frankly, speaking for the OpenLDAP Project, what we want is to delete all 
support for GnuTLS. It is, like Mozilla NSS, a poorly designed API with 
requirements that are impossible to satisfy in the real world, and more 
trouble than it's worth.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 08:30:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 08:30:04 GMT) Full text and rfc822 format available.

Message #232 received at 368297@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Michael Gilbert <mgilbert@debian.org>
Cc: 368297@bugs.debian.org
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 10:22:08 +0200
On Fri, 19 Apr 2013 02:52, mgilbert@debian.org said:
>>> 1.a) Patch libgcrypt to revert commit
>>>      d769529a71ccda4e833f919f3c5693d25b005ff0
>>
>> Urgs.  That is a short sighted fix.
>
> That seems to be the solution the rest of the open source community is
> converging toward.  Short sighted is an odd categorization since it
> seems to have taken 8 years to come to this conclusion.

Misunderstanding?  With "a short sighted fix" I mean 1.a; that is the
proposal to _revert_ commit d769529.

Anyway, this commit is there for a good reason; I can't remember any
details but for sure Moritz had a valid reason to do this.  Those who
are interested may want to do dig the gnupg/gcrypt/poldi archives.

The whole mess comes from the idea that a library is able to deduce what
the application wants to do without the application telling it.  Now if
a library is used indirectly by the application and often also from
several libraries and even from the application itself, conflicts will
arise.  Thus we have always told that an application must be aware of
_all_ code it is using in its process.  Thus libraries may need to
expose an interface to the application even if they are used indirectly.
Using shared libraries is not easy and sometimes it is impossible to get
things right (in OSes where shared libraries have been added as an
afterthought).  And yes, Libgcrypt is not an exception: It also does
guess working and assumes that complex application won't run suid.  And
it tries to be as failsafe as possible by trying hard to initialize
itself if the application forgot to do that.

It seems the main reason for all that hassle is the ad-hoc architecture
of PAM being a set of libraries instead of a daemon and a library to
access that daemon (like userv(1)).  PAM's track record of security
problems might be an indication of that architectural problem.

> Maybe some of the blogs on the issue and other comments in this bug
> log would be of useful to understand why.  For example:
> http://jdbates.blogspot.ca/2013/04/its-crazy-how-much-time-and-effort-one.html

While we are in the business of refreshing our URL memories, let me
follow up with:

 http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198

Florian Weimer comes to the same conclusion regarding the PAM
architecture but also asked why we still need a suid for mlock.  The
simple reason is that some installations still use suid(e.g. gpg) and
rely on Libgcrypt dropping the privileges.  Thus we can't change that.

A solution would be that the application explicitly tells us not to drop
the privileges.  libpam can't do that because it does not know anything
about the application.  But wait, the bug at hand is about a specific
application and thus sudo would be able to tell libgcrypt what to do.
Adding a global flag to Libgcrypt to skip privilege dropping will not be
hard; let me know if this could be a way forward.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 08:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 08:45:05 GMT) Full text and rfc822 format available.

Message #237 received at 368297@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Howard Chu <hyc@symas.com>
Cc: Carlos Alberto Lopez Perez <clopez@igalia.com>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, 368297@bugs.debian.org, Simon Fondrie-Teitler <simonft@riseup.net>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 10:36:07 +0200
On Fri, 19 Apr 2013 09:22, hyc@symas.com said:

> Excuse me? By what measure is this correct? Certainly not by any
> published official documentation.

The correct solution is to let the application handle this.  But I don't
want to repeat this now.  "most correct" here means, it is not worse
than what GNUTLS or any other library might do in case requirements
(initialization of Libgcrypt) have not been met.

As a historic note let me add that Nikos, the GNUTLS author, once
approached me to find way to avoid passing an initialization hook up to
the application.  After a lot of discussion we finally came up with this
INITIALIZATION_FINISHED_P hack.

> The OpenLDAP library doesn't want one thing or another at all. It
> simply is expected to use GnuTLS on Debian and it initializes it as
> documented.

Well, it also needs to initialize Libgcrypt.  But GNUTLS takes care of
it and tries to do the Right Thing if that has not been done.  Which
works in most cases.

> Frankly, speaking for the OpenLDAP Project, what we want is to delete
> all support for GnuTLS. It is, like Mozilla NSS, a poorly designed API

Split OpenLDAP into a daemon and a simple access library and things
would be more robust.  This also avoids the hard library dependencies
and the need for applications to runtime link to several versions of the
same library.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 09:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Howard Chu <hyc@symas.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 09:15:05 GMT) Full text and rfc822 format available.

Message #242 received at 368297@bugs.debian.org (full text, mbox):

From: Howard Chu <hyc@symas.com>
To: Werner Koch <wk@gnupg.org>
Cc: Carlos Alberto Lopez Perez <clopez@igalia.com>, "Adam D. Barratt" <adam@adam-barratt.org.uk>, 368297@bugs.debian.org, Simon Fondrie-Teitler <simonft@riseup.net>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 02:12:20 -0700
Werner Koch wrote:
> On Fri, 19 Apr 2013 09:22, hyc@symas.com said:
>> Frankly, speaking for the OpenLDAP Project, what we want is to delete
>> all support for GnuTLS. It is, like Mozilla NSS, a poorly designed API
>
> Split OpenLDAP into a daemon and a simple access library and things
> would be more robust.  This also avoids the hard library dependencies
> and the need for applications to runtime link to several versions of the
> same library.

You're absolutely right. That's why nss-pam-ldapd exists, and why OpenLDAP has 
supported it (using either nssov or nslcd) since June 2008. We've spent enough 
time on this, it's past time to move on.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/



Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 16:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 16:57:04 GMT) Full text and rfc822 format available.

Message #247 received at 368297@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: Werner Koch <wk@gnupg.org>, 368297@bugs.debian.org
Cc: Michael Gilbert <mgilbert@debian.org>, Moritz Schulte <mo@g10code.com>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 18:54:25 +0200
[Message part 1 (text/plain, inline)]
On 19/04/13 10:22, Werner Koch wrote:
> On Fri, 19 Apr 2013 02:52, mgilbert@debian.org said:
>>>> >>> 1.a) Patch libgcrypt to revert commit
>>>> >>>      d769529a71ccda4e833f919f3c5693d25b005ff0
>>> >>
>>> >> Urgs.  That is a short sighted fix.
>> >
>> > That seems to be the solution the rest of the open source community is
>> > converging toward.  Short sighted is an odd categorization since it
>> > seems to have taken 8 years to come to this conclusion.
> Misunderstanding?  With "a short sighted fix" I mean 1.a; that is the
> proposal to _revert_ commit d769529.
> 
> Anyway, this commit is there for a good reason; I can't remember any
> details but for sure Moritz had a valid reason to do this.  Those who
> are interested may want to do dig the gnupg/gcrypt/poldi archives.

I couldn't find anything relevant on the archives.

Saying that there is a good reason for this commit to be there and at
the same time saying that such good reason is unknown...  won't help.

It would be good to know which good reason is that. Not only for the
sake of getting this bug fixed, but also because the Ubuntu guys went
the way of reverting d769529. So, if reverting this commit could cause
some security issue or any other kind of problem it will be good to know
it before the harm is done.

I'm CC'ing Moritz, perhaps he can throw a bit of light here.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 17:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 17:15:04 GMT) Full text and rfc822 format available.

Message #252 received at 368297@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Carlos Alberto Lopez Perez <clopez@igalia.com>
Cc: 368297@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>, Moritz Schulte <mo@g10code.com>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 19:07:02 +0200
On Fri, 19 Apr 2013 18:54, clopez@igalia.com said:

> I couldn't find anything relevant on the archives.

Next step would be to check the repos and all packages using Libgcrypt.

> Saying that there is a good reason for this commit to be there and at
> the same time saying that such good reason is unknown...  won't help.

I can't see that there is anything wrong with that patch.  We need to
initialize Libgcrypt as early as possible to avoid subtle bugs by
software not using Libgcrypt correctly.

> the way of reverting d769529. So, if reverting this commit could cause
> some security issue or any other kind of problem it will be good to know

At least in FIPS mode Libgcrypt should detect such a problem itself.
But well, who is abale to use FIPS mode.

> I'm CC'ing Moritz, perhaps he can throw a bit of light here.

He is dropped his job at g10 Code many years ago, thus don't put too
much hope into it.

What about my suggestion on how to solve the problem?


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 17:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 17:27:04 GMT) Full text and rfc822 format available.

Message #257 received at 368297@bugs.debian.org (full text, mbox):

From: Julien Cristau <jcristau@debian.org>
To: Werner Koch <wk@gnupg.org>, 368297@bugs.debian.org
Cc: Carlos Alberto Lopez Perez <clopez@igalia.com>, Michael Gilbert <mgilbert@debian.org>, Moritz Schulte <mo@g10code.com>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 19:25:04 +0200
[Message part 1 (text/plain, inline)]
On Fri, Apr 19, 2013 at 19:07:02 +0200, Werner Koch wrote:

> What about my suggestion on how to solve the problem?
> 
If that "solution" is to have sudo itself call into libgcrypt, that
doesn't sound like a solution at all.  sudo doesn't know how libldap
implements crypto, it doesn't care, and it shouldn't have to care IMO.

Cheers,
Julien
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 17:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 17:48:04 GMT) Full text and rfc822 format available.

Message #262 received at 368297@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: Julien Cristau <jcristau@debian.org>
Cc: Werner Koch <wk@gnupg.org>, 368297@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>, Moritz Schulte <mo@g10code.com>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 19:44:25 +0200
[Message part 1 (text/plain, inline)]
On 19/04/13 19:25, Julien Cristau wrote:
> On Fri, Apr 19, 2013 at 19:07:02 +0200, Werner Koch wrote:
> 
>> What about my suggestion on how to solve the problem?
>>
> If that "solution" is to have sudo itself call into libgcrypt, that
> doesn't sound like a solution at all.  sudo doesn't know how libldap
> implements crypto, it doesn't care, and it shouldn't have to care IMO.
> 

Also, is not only sudo the program that is broken, but *any* setuid
binary that chains into libldap->libgcrypt (aka calls getpwent() and
family). This includes among others: passwd, sudo and su

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 18:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 18:21:05 GMT) Full text and rfc822 format available.

Message #267 received at 368297@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: Werner Koch <wk@gnupg.org>, 368297@bugs.debian.org
Cc: Michael Gilbert <mgilbert@debian.org>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 20:15:57 +0200
[Message part 1 (text/plain, inline)]
On 19/04/13 10:22, Werner Koch wrote:
> While we are in the business of refreshing our URL memories, let me
> follow up with:
> 
>  http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198
> 
> Florian Weimer comes to the same conclusion regarding the PAM
> architecture but also asked why we still need a suid for mlock.  The
> simple reason is that some installations still use suid(e.g. gpg) and
> rely on Libgcrypt dropping the privileges.  Thus we can't change that.

I'm sure in the past was a good reason to do this (mlock required suid)
but nowadays is not longer the case and you can see it causes more
trouble than benefit.

What about removing this feature of dropping privileges from libgcrypt
and adding it to gpg itself? gpg could check if is run suid and drop
itself the privileges without relying on libgcrypt to do that.

This way you avoid the security problem of letting old installations run
gpg suid, and the rest of the world can use the secmem feature of
libgcrypt without the dropping privileges problem.

Otherwise is just impossible for any suid application (that wants to
stay suid) to use the libgcrypt secmem feature. Developers of this
applications end disabling the secmem feature to avoid that, which in
turns causes more harm than good to the security of the system.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 19:06:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 19:06:09 GMT) Full text and rfc822 format available.

Message #272 received at 368297@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Carlos Alberto Lopez Perez <clopez@igalia.com>
Cc: 368297@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 20:56:04 +0200
On Fri, 19 Apr 2013 20:15, clopez@igalia.com said:

> What about removing this feature of dropping privileges from libgcrypt
> and adding it to gpg itself? gpg could check if is run suid and drop

I already explained that this is not possible because we can't know the
applications which rely on this behaviour.  The packages in Debian are
by far not the only software in use by Debian users.  Most software is
production critical software which assumes that thee OS (e.g. Debian)
does its job right.  Thus it is irresponsible to sneak in such a change.

> Otherwise is just impossible for any suid application (that wants to
> stay suid) to use the libgcrypt secmem feature. Developers of this

Any suid application using libgcrypt/gnutls/openldap/complex-o-code
before dropping privileges is a sleeping security problem.  You will
never be able to get them right.  We are now in 2013 and over the course
of the last two decades (and the rise of the Internet as an unfriendly
place) all programmer should have learned that they need to take great
care with suid code and that code size matters.

Having said this, I don't see a reason why not to put the
responsibilities in the hands of the suid program authors.  They anyway
wake up every night due to a nightmare telling them to check this and
that and - oh - I am using a library I didn't checked for 2 releases;
lets set 2 years aside for another full audit of my entire program.
Adding two lines of code right at startup shouldn't make their headaches
worse.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 19:33:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 19:33:04 GMT) Full text and rfc822 format available.

Message #277 received at 368297@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Julien Cristau <jcristau@debian.org>
Cc: 368297@bugs.debian.org, Carlos Alberto Lopez Perez <clopez@igalia.com>, Michael Gilbert <mgilbert@debian.org>, Moritz Schulte <moritz@gnu.org>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 21:23:28 +0200
On Fri, 19 Apr 2013 19:25, jcristau@debian.org said:

> If that "solution" is to have sudo itself call into libgcrypt, that
> doesn't sound like a solution at all.  sudo doesn't know how libldap
> implements crypto, it doesn't care, and it shouldn't have to care IMO.

Uh-oh.  A suid program that does not care what code it uses?

Folks, please read some basics about secure programming and then back to
the drawing board.  I remember a time Debian was proud of its good
security policies :-(.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 20:42:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 20:42:09 GMT) Full text and rfc822 format available.

Message #282 received at 368297@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: Werner Koch <wk@gnupg.org>
Cc: 368297@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Fri, 19 Apr 2013 22:37:59 +0200
[Message part 1 (text/plain, inline)]
On 19/04/13 20:56, Werner Koch wrote:
> Having said this, I don't see a reason why not to put the
> responsibilities in the hands of the suid program authors.  They anyway
> wake up every night due to a nightmare telling them to check this and
> that and - oh - I am using a library I didn't checked for 2 releases;
> lets set 2 years aside for another full audit of my entire program.
> Adding two lines of code right at startup shouldn't make their headaches
> worse.

Basically because the authors of this programs don't know they are using
libgcrypt under the hood. And they shouldn't know.

They just call a standard function (ex: getpwent). This function may or
may not chain with libgcrypt depending on how the system libraries are
compiled and how the system is configured.

On the case of a Debian system configured to use PAM/LDAP this will
chain to libldap->libgrypt.

The two patches proposed to fix this problem until now, what are doing
under the hood, is basically disable the secmem feature of libgcrypt to
prevent the dropping privileges problem. This is a suboptimal solution.
I think that anybody would agree that the usage of "mlocked" memory
regions for this kind of data like passwords is encouraged.

The whole initialization routine of GnuTLS (which is right now broken
for a threaded application that sets GCRYCTL_SET_THREAD_CBS by the
libgcrypt commit d769529) disables secmem [1]. This is why reverting
that commit fixes this bug (fixes the GnuTLS init routine).

Why would anyone ever want to to disable the usage of secmem when
handling such critical data as a TLS library could handle? Just to avoid
the dropping privileges problem?? Is just insane!

At least, I think that you should consider adding a new flag to
libgcrypt that allows the application/library developer to complete
disable the dropping privileges feature. Perhaps something like:
GCRYCTL_INIT_SECMEM_NODROP_PRIVS


IMHO is not the business of libgcrypt to care about the security of the
application that uses it. And dropping privileges for the caller
application when not directly asked is, at least, rude.

The programmer of the suid application should care himself about
dropping privileges when he feels like that. If you force him to drop
privileges he will just skip your secmem routine. This is bad for everyone.



[1]
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/gcrypt/init.c;h=3d69f44

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 22:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 22:15:04 GMT) Full text and rfc822 format available.

Message #287 received at 368297@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Carlos Alberto Lopez Perez <clopez@igalia.com>
Cc: 368297@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Sat, 20 Apr 2013 00:08:23 +0200
On Fri, 19 Apr 2013 22:37, clopez@igalia.com said:

> They just call a standard function (ex: getpwent). This function may or
> may not chain with libgcrypt depending on how the system libraries are
> compiled and how the system is configured.

Okay, then it is the fault of the libnss code to allow the use of
complex code not suited for suid processes.  After all it boils down to
a design problem of libpam.

> On the case of a Debian system configured to use PAM/LDAP this will
> chain to libldap->libgrypt.

I still can't believe it.

> prevent the dropping privileges problem. This is a suboptimal solution.
> I think that anybody would agree that the usage of "mlocked" memory
> regions for this kind of data like passwords is encouraged.

Not necessary if you the swap space is encrypted.  This provides an even
better port-mortem protection than mlock.

> The whole initialization routine of GnuTLS (which is right now broken
> for a threaded application that sets GCRYCTL_SET_THREAD_CBS by the

Surely it is broken.  Only the application itself can guarantee that the
threading system has been properly initialized.  A library can only try
its best to avoid future damage.

> handling such critical data as a TLS library could handle? Just to avoid
> the dropping privileges problem?? Is just insane!

Running code conveying data over the network in a suid process is evil!

> At least, I think that you should consider adding a new flag to
> libgcrypt that allows the application/library developer to complete
> disable the dropping privileges feature. Perhaps something like:

That was my suggesttion.  Shall we go for that?

> IMHO is not the business of libgcrypt to care about the security of the
> application that uses it. And dropping privileges for the caller
> application when not directly asked is, at least, rude.

IMNSHO Libgcrypt needs to do it because its post-initialization layers
have not been designed for a suid process.

> The programmer of the suid application should care himself about
> dropping privileges when he feels like that. If you force him to drop
> privileges he will just skip your secmem routine. This is bad for everyone.

Nope: SUID processes are bad and should only be used if really really
necessary.  In contrast mlocked memory is a nice to have feature but the
attack scenarios are pretty limited compared to networking suid code.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 19 Apr 2013 23:39:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 19 Apr 2013 23:39:15 GMT) Full text and rfc822 format available.

Message #292 received at 368297@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: Werner Koch <wk@gnupg.org>
Cc: 368297@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Sat, 20 Apr 2013 01:35:54 +0200
[Message part 1 (text/plain, inline)]
On 20/04/13 00:08, Werner Koch wrote:
>> At least, I think that you should consider adding a new flag to
>> > libgcrypt that allows the application/library developer to complete
>> > disable the dropping privileges feature. Perhaps something like:
> That was my suggesttion.  Shall we go for that?
> 

I think it would be a good idea to add this feature to libgcrypt.

However, I don't think that it would help us with this specific Debian
bug because it would be implemented as an optional feature.

And the suid application (sudo/su/passwd/...) can't know anything about
libgcrypt, so it can't set this flag or any other libgcrypt flag.

So the only option would be to set the flag either in gnutls or libldap.
And this is more or less what the previous proposed patches are doing by
disabling secmem.


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Sat, 20 Apr 2013 00:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Sat, 20 Apr 2013 00:09:04 GMT) Full text and rfc822 format available.

Message #297 received at 368297@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Carlos Alberto Lopez Perez <clopez@igalia.com>
Cc: 368297@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Sat, 20 Apr 2013 02:04:12 +0200
[Message part 1 (text/plain, inline)]
On Sat, 20 Apr 2013 01:35, clopez@igalia.com said:

> I think it would be a good idea to add this feature to libgcrypt.

See attached patch against master.  It is not tested, though.  You may
backport it to 1.5 and use it like this:

#if GCRYPT_VERSION_NUMBER > 0x010502
    gcry_control (GCRYCTL_DISABLE_PRIV_DROP, 0);
#endif /* libgcrypt > 1.5.2 */

> However, I don't think that it would help us with this specific Debian
> bug because it would be implemented as an optional feature.

I can't understand what you want to say.

> And the suid application (sudo/su/passwd/...) can't know anything about
> libgcrypt, so it can't set this flag or any other libgcrypt flag.

The application (sudo,su,passwd) needs to set this flag!  No library is
able to know what the applications wants.  Optionally you may put
wrappers in the mentioned libraries, but that makes things more
complicated and fragile.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
[0001-Add-control-commands-to-disable-mlock-and-setuid-dro.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Sat, 20 Apr 2013 18:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Sat, 20 Apr 2013 18:21:04 GMT) Full text and rfc822 format available.

Message #302 received at 368297@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: Werner Koch <wk@gnupg.org>
Cc: 368297@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Sat, 20 Apr 2013 20:18:25 +0200
[Message part 1 (text/plain, inline)]
On 20/04/13 02:04, Werner Koch wrote:
> On Sat, 20 Apr 2013 01:35, clopez@igalia.com said:
> 
>> I think it would be a good idea to add this feature to libgcrypt.
> 
> See attached patch against master.  It is not tested, though.  You may
> backport it to 1.5 and use it like this:
> 
> #if GCRYPT_VERSION_NUMBER > 0x010502
>     gcry_control (GCRYCTL_DISABLE_PRIV_DROP, 0);
> #endif /* libgcrypt > 1.5.2 */
> 
Thanks for the patch :)

Are you planning to merge it upstream?

I believe it will be useful for everyone that asked for this feature on
the past and ended workarounding the problem by disabling secmem.

One examples of that is cryptsetup :

https://code.google.com/p/cryptsetup/source/browse/lib/crypto_backend/crypto_gcrypt.c#55


>> However, I don't think that it would help us with this specific Debian
>> bug because it would be implemented as an optional feature.
> 
> I can't understand what you want to say.
> 

I was meaning that this patch adds a flag (GCRYCTL_DISABLE_PRIV_DROP)
that the application should enable.

Therefore, after patching libgcrypt with the patch you provided to add
support for this flag, is still needed to patch either libldap or gnutls
to enable the flag.

So, to fix this Debian bug with this approach, we will need patching at
least two packages:

 1. libgcrypt (to add support for the flag).
 2. openldap or gnutls (to enable the flag).

This is probably a bigger diff change than the previous ones proposed,
and maybe the release team is not happy with that at this point of the
freeze.

>> And the suid application (sudo/su/passwd/...) can't know anything about
>> libgcrypt, so it can't set this flag or any other libgcrypt flag.
> 
> The application (sudo,su,passwd) needs to set this flag!  No library is
> able to know what the applications wants.  Optionally you may put
> wrappers in the mentioned libraries, but that makes things more
> complicated and fragile.
> 

IMHO is just impossible to add this at the application level. This
applications don't have a dependency on libgcrypt. They don't use any
library or symbol related to libgcrypt. So (i guess) asking their
developers to introduce a dependency on libgcrypt just to enable such
flag is a no-go.

This applications just happen to have a dependency on libpam.

And when PAM is configured to use LDAP as backend, the libpam-ldap
module for PAM will chain to libldap (openldap). Then, libldap will need
to use gnutls and libgcrypt related functions to talk to the LDAP
backend *if* this one has SSL enabled.

So, we have the following chain of successes:

sudo/passwd/su/etc -> libpam ---(if system==PAM/LDAP)--> libpam-ldap ->
libldap ---(if URI==ldaps://)--> gnutls -> libgcrypt



And the first "libgcrypt aware" library on this chain is libldap
(openldap). The previous ones on the chain have no idea about libgcrypt.


Therefore such flag could only be enabled at libldap or gnutls.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Sat, 20 Apr 2013 18:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Sat, 20 Apr 2013 18:27:04 GMT) Full text and rfc822 format available.

Message #307 received at 368297@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: Werner Koch <wk@gnupg.org>
Cc: 368297@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Sat, 20 Apr 2013 20:25:29 +0200
[Message part 1 (text/plain, inline)]
On 20/04/13 20:18, Carlos Alberto Lopez Perez wrote:
> So, we have the following chain of successes:
                                     ^ events
> 
> sudo/passwd/su/etc -> libpam ---(if system==PAM/LDAP)--> libpam-ldap ->
> libldap ---(if URI==ldaps://)--> gnutls -> libgcrypt


[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Sun, 21 Apr 2013 08:51:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Werner Koch <wk@gnupg.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Sun, 21 Apr 2013 08:51:04 GMT) Full text and rfc822 format available.

Message #312 received at 368297@bugs.debian.org (full text, mbox):

From: Werner Koch <wk@gnupg.org>
To: Carlos Alberto Lopez Perez <clopez@igalia.com>
Cc: 368297@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>
Subject: Re: Bug#368297: About the libgcrypt and OpenLDAP issue
Date: Sun, 21 Apr 2013 10:41:55 +0200
On Sat, 20 Apr 2013 20:18, clopez@igalia.com said:

> Are you planning to merge it upstream?

Sure.  Unfortunately I released 1.5.2 just a few days ago.  Thus it
won't happen in the next few weeks.

> I believe it will be useful for everyone that asked for this feature on
> the past and ended workarounding the problem by disabling secmem.

[Why don't they ask on gcrypt-devel@ or add a feature request into the
tracker].

> I was meaning that this patch adds a flag (GCRYCTL_DISABLE_PRIV_DROP)
> that the application should enable.

Right.

> Therefore, after patching libgcrypt with the patch you provided to add
> support for this flag, is still needed to patch either libldap or gnutls
> to enable the flag.

Wrong.  This would be a surpising policy change.

>  1. libgcrypt (to add support for the flag).

Yes.  There are anyway to required bug fixes for ECC pending.

> This is probably a bigger diff change than the previous ones proposed,
> and maybe the release team is not happy with that at this point of the
> freeze.

I explained it several times: You can't do that in a library.  I even
won't do that without an _API_ break in Libgcrypt.  If we break the API
it would be possible to do just because everyone is then required to
read the release notes.

> IMHO is just impossible to add this at the application level. This
> applications don't have a dependency on libgcrypt. They don't use any

If they don't have a dependency we could close the bug immediately.

> library or symbol related to libgcrypt. So (i guess) asking their
> developers to introduce a dependency on libgcrypt just to enable such

It is already there ...

> This applications just happen to have a dependency on libpam.

... due to this dependency.

> And when PAM is configured to use LDAP as backend, the libpam-ldap
> module for PAM will chain to libldap (openldap). Then, libldap will need

Do you want to say that dlopen does not introduce a dependency?
Actually it introduces a very fragile dependency.  I don't know how this
could be handled without a strict plugin interface which does only allow
the use modules with any external dependencies.

> And the first "libgcrypt aware" library on this chain is libldap
> (openldap). The previous ones on the chain have no idea about libgcrypt.

Well, then you could add a wrapper to libldap to set the new Libgcrypt
flag.  But you need to dlopen libldap (respective the plugin using
libldap) right after main.  Any other call sequence might indirectly
load Libgcrypt via different code paths (plugins) before libldap has a
chance to set the flag.

The bottom line is that the architecture of PAM is severely broken due to
its in-process plugin interface.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Mon, 22 Apr 2013 16:33:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Mon, 22 Apr 2013 16:33:16 GMT) Full text and rfc822 format available.

Message #317 received at 368297@bugs.debian.org (full text, mbox):

From: Julien Cristau <jcristau@debian.org>
To: Carlos Alberto Lopez Perez <clopez@igalia.com>, 368297@bugs.debian.org
Cc: Andreas Metzler <ametzler@downhill.at.eu.org>, adam.stokes@canonical.com, 545414@bugs.debian.org, 566351@bugs.debian.org, 579647@bugs.debian.org, 601667@bugs.debian.org, 628671@bugs.debian.org, 658896@bugs.debian.org, pkg-openldap-devel@lists.alioth.debian.org, pkg-gnutls-maint@lists.alioth.debian.org, control@bugs.debian.org
Subject: Re: Bug#368297: [PATCH] Fix dropping privileges issue on setuid programs on systems with PAM/LDAP and GnuTLS/libgcrypt
Date: Mon, 22 Apr 2013 18:30:11 +0200
[Message part 1 (text/plain, inline)]
tags 368297 + wheezy-ignore
user release.debian.org@packages.debian.org
usertag 368297 + wheezy-can-defer

On Fri, Jan 25, 2013 at 00:44:21 +0100, Carlos Alberto Lopez Perez wrote:

> When sudo/su/passwd/<insert-any-setuid-program-that-calls-getpwent()> on
> a system configured with PAM/LDAPs it chains into libldap, which uses
> GnuTLS/libgcrypt to manage the TLS channel.
> 
So I've tried to reproduce that, by installing sudo-ldap, slapd,
lib{nss,pam}-ldap, ssl-cert and configuring stuff to use
ldaps://localhost.  Seems like things work when the user is in
/etc/passwd, and fail if they're in ldap.
The failure goes away when switching to lib{nss,pam}-ldapd, which was
already the recommended workaround for this bug in squeeze.

I understand that some use cases aren't supported by this alternative,
but:
- AIUI this was already the case in squeeze
- the way forward is probably to improve on them, for jessie, not try
  and keep lib{nss,pam}-ldap around indefinitely

Cheers,
Julien
[signature.asc (application/pgp-signature, inline)]

Added tag(s) wheezy-ignore. Request was from Julien Cristau <jcristau@debian.org> to control@bugs.debian.org. (Mon, 22 Apr 2013 16:33:37 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Fri, 03 May 2013 00:39:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jack Bates <8it1g1@nottheoilrig.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Fri, 03 May 2013 00:39:04 GMT) Full text and rfc822 format available.

Message #324 received at 368297@bugs.debian.org (full text, mbox):

From: Jack Bates <8it1g1@nottheoilrig.com>
To: 368297@bugs.debian.org
Subject: How to check if the application forgot to initialize Libgcrypt?
Date: Thu, 02 May 2013 17:36:49 -0700
Whether the OpenLDAP code that depends on GnuTLS is in a separate 
process from the application or not, it might still need to set 
Libgcrypt thread support callbacks when it initializes GnuTLS.

Werner Koch makes the point that ideally the application (nss-pam-ldapd 
or whatever) would initialize Libgcrypt. Meanwhile everyone seems to 
agree that a library which introduces an indirect dependency on 
Libgcrypt (i.e. GnuTLS) should be failsafe and initialize Libgcrypt 
itself if the application forgot to do that.

Then how should it check if the application forgot to initialize 
Libgcrypt? Testing GCRYCTL_ANY_INITIALIZATION_P is consistent with 
Libgcrypt documentation...



Information forwarded to debian-bugs-dist@lists.debian.org, Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>:
Bug#368297; Package libgcrypt11. (Tue, 05 Nov 2013 14:48:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Carlos Alberto Lopez Perez <clopez@igalia.com>:
Extra info received and forwarded to list. Copy sent to Debian GnuTLS Maintainers <pkg-gnutls-maint@lists.alioth.debian.org>. (Tue, 05 Nov 2013 14:48:05 GMT) Full text and rfc822 format available.

Message #329 received at 368297@bugs.debian.org (full text, mbox):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>
To: Thorsten Glaser <tg@mirbsd.de>
Cc: 658739@bugs.debian.org, 368297@bugs.debian.org, Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
Subject: Does OpenLDAP has any GPLv2 dependency?
Date: Tue, 05 Nov 2013 15:45:07 +0100
[Message part 1 (text/plain, inline)]
On 24/04/12 17:25, Thorsten Glaser wrote:
> Hi all,
> 
> this bug has been brought to my attention by my boss today.
> If I understand the situation correctly, the problem is:
> 
> • OpenLDAP links against GnuTLS (gnutls26)
> • gnutls26 links against gcrypt, which has the bug
> • gnutls28 links against nettle, but also gmp which is LGPLv3+
> • OpenLDAP thus can’t link against gnutls28, as it has reverse
>   dependencies that are not LGPLv3-/GPLv3-compatible
> • the package affected is libnss-ldap though
> 

Which ones are the reverse dependencies of libnss-ldap or OpenLDAP that
are LGPLv3+ incompatibles?

According to [1], the only combination forbidden is GPLv2 (LGPLv2 and
LGPLv2.1 is allowed per point 3. of the license, explained also on [1] ).

Looking at the recursive reverse dependencies of libnss-ldap [2] I fail
to find any package that is GPLv2 only.

If there isn't any GPLv2 reverse dependency, then OpenLDAP can be just
recompiled to link against gnutls28 and this long standing bug will be
fixed.

Thoughts?


Regards!
--------

[1] https://bugzilla.redhat.com/show_bug.cgi?id=986347
[2] $ apt-rdepends libnss-ldap



[signature.asc (application/pgp-signature, attachment)]

Added tag(s) squeeze-ignore. Request was from Andreas Beckmann <anbe@debian.org> to control@bugs.debian.org. (Wed, 06 Nov 2013 02:33:17 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 10:15:41 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.