This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Security impact of nscd and NSS module bugs (particularly NIS)
- From: Rich Felker <dalias at libc dot org>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Sat, 5 Jul 2014 08:48:41 -0400
- Subject: Re: Security impact of nscd and NSS module bugs (particularly NIS)
- Authentication-results: sourceware.org; auth=none
- References: <53B54CEE dot 6040505 at redhat dot com> <20140703160829 dot GW20796 at spoyarek dot pnq dot redhat dot com> <20140703193030 dot 93B502C398D at topped-with-meat dot com> <53B670B1 dot 4090103 at redhat dot com> <20140704192258 dot 991952C39B8 at topped-with-meat dot com> <20140705030009 dot GH179 at brightrain dot aerifal dot cx> <871tu0then dot fsf at igel dot home>
On Sat, Jul 05, 2014 at 09:05:04AM +0200, Andreas Schwab wrote:
> Rich Felker <dalias@libc.org> writes:
>
> > Isn't just eliminating the unwanted modules from /etc/nsswitch.conf
> > the natural way to prevent fallback on the client side?
>
> That will affect nscd as well.
Yes, but adding a new option to suppress loading only on the client
side would fail to suppress it in older glibc versions, including
static-linked ones. That seems like a failure from a security
standpoint. On the other hand, removing the modules in
/etc/nsswitch.conf would protect all clients and nscd could easily be
built to use a different configuration than the one in
/etc/nsswitch.conf.
Personally I would love for this kind of setup to become the default,
since loading nss modules (especially anything custom or not widely
used) into every application is a nightmare from a security
standpoint, not to mention namespace-safety, and of course breaks
static linking.
Rich