Bug#566351: libgcrypt11: should not change user id as a side effect

[Ansgar Burchardt]

Werner Koch <wk at gnupg.org> writes:

> On Mon, 25 Jan 2010 16:13, ansgar at 43-1.org said:
>
>> Yes, it is even quite simple to write such an application: Just call
>> getgroups(), getpwent(), ... on a system that uses LDAP.  If there is no
>> caching daemon like nscd running, the application will use libnss-ldap
>> (via glibc's Name Service Switch) which can in turn use gnutls.
>
> That is a broken design.  glibc should never ever allow suid processes
> to run code from external services it is not 100% sure they are clean.
> I guess libnss_files and the other standard ones might be fine, but LDAP
> or even LDAPS are very problematic.  Such code belongs into a separate
> process and not into the one of an arbitrary - possible suid -
> application.

It can run in a separate process if nscd (glibc's name service caching
daemon) is running.  But if nscd is not installed or not running for
some reason, there is not much to do except doing the query in the same
process.

gcrypt's behavior also does not only affect suid processes, but also
processes started by root that change their real user id to something
else, but still need to change to a different user id later.

>> As the application itself does not use openldap, gnutls, or gcrypt there
>> is no way it could initialize gcrypt.
>
> You may consider this a featue - it indicates that there is something
> severly wrong with the application running on a particular system
> configuration.

There are enough sensible reasons for an application using gcrypt only
indirectly (eg. applications using gnutls should not need to care which
cryptographic library is used by it, more so for applications that only
use a library like libcurl that uses gnutls, but can also use OpenSSL).

Regards,
Ansgar