Bug#368297: About the libgcrypt and OpenLDAP issue

[Carlos Alberto Lopez Perez]

On 20/04/13 02:04, Werner Koch wrote:
> On Sat, 20 Apr 2013 01:35, clopez at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20130420/06008960/attachment.pgp>