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

[Florian Weimer]

* Werner Koch:

> 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.

The libc jas no business policing user code in this way.  NSS and PAM
modules already need to be SUID-safe, and there's really no way around
that.  A process-based solution for PAM and NSS might have been
preferable, but it's rather late for that now.

One side effect of dropping privileges is that some code no longer
treats the process environment as tainted, leading to security issues
if the process has opened descriptors while it had increased
privilege.  Beyond getuid() != geteuid(), there is really no good way
to check for a tainted environment, alas.

But the whole discussion is rather odd.  I thought that access to
locked memory no longer requires root privileges, no?

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99