Yes, it is unlikely you can pare thibgs down more than klibc. Vivek Goyal <vgoyal at redhat.com> wrote: >On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote: >> Vivek Goyal <vgoyal at redhat.com> writes: >> >> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: >> >> >> >> It needs to be checked but /sbin/kexec should not use any >functions that >> >> trigger nss switch. No user or password or host name lookup >should be >> >> happening. >> > >> > I also think that we don't call routines which trigger nss switch >but >> > be probably can't rely on that as somebody might introduce it in >> > future. So we need more robust mechanism to prevent it than just >code >> > inspection. >> >> The fact that we shouldn't use those routines is enough to let us >> walk down a path where they are not used. Either with a static glibc >> linked told to use no nss modules (--enable-static-nss ?), or with >> another more restricted libc. > >Is there anything wrong with using uClibc? Trying to link again >customized glibc (with --enable-static-nss) sounds just extra work for >build environments. Are there know restricted libc or we need to create >one with passing more compile time options to libc. > >Instead of doing more work in an attempt to create restricted libc, >it might be easier to just link against any already available >restricted library. > >Thanks >Vivek -- Sent from my mobile phone. Please excuse brevity and lack of formatting.
