From: Stephen Frost (sfrost_at_snowman.net)
Date: Sat 09 Apr 2005 - 03:48:53 BST
* Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de) wrote:
> sfrost_at_snowman.net (Stephen Frost) writes:
> >> according to Enrico (please confirm or correct) the glibc has issues
> >> with the fake name resolver and is generally considered insecure
> >> because usually dynamically linked ...
> > This really needs further explanation and justification. What about
> > glibc being dynamically linked (and able to load other libraries)
> > makes it insecure, specifically?
> 1. 'insecure', because the dynamical loading of libnss_* is
> uncontrollable. There is no (documented??) way to disable this
> loading e.g. when the chroot was entered. Executing a function which
> would load an nss-library does not give any guarantee that the next
> call to this function with another argument would not load another
It's not uncontrollable- just don't call NSS functions after you've
chroot'd. Is there some reason that's a problem?
> 2. the glibc NSS implementation uses caching/optimization which can
> cause failures in chroot operations. E.g. when the 'getpwnam()'
> before chroot(2) (which is used to load the libnss_* libraries)
> creates a connection to the 'nscd' daemon, this connection will be
> used for the second 'getpwnam()' (after chroot(2)) also, which will
> return wrong results.
> You will see this issue with rpm based vserver-build methods when the
> tools are compiled with glibc and nscd is running.
I guess I'll have to look at the code but it would have been nice if you
could have at least addressed the question of why it's a problem to just
avoid calling NSS functions after the chroot() that I raised in my
> > What changes would need to be done to make use of it
> > secure?
> Provide a way to:
> * disable dynamic libnss_* loading
> * disable usage of nscd
It'd be nice to be able to do this but I don't see them as being
necessary to have secure tools.
Vserver mailing list