About this list Date view Thread view Subject view Author view Attachment view

From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Sat 09 Apr 2005 - 02:11:14 BST

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

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.

> 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


Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Sat 09 Apr 2005 - 02:23:47 BST by hypermail 2.1.3