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. >> This is one part in hardening /sbin/kexec to deal with hostile root >> users. We need to check crazy things like do the files we open on /proc >> actually point to /proc after we have opened them. > > Can you please explain it more. How can one fiddle with /proc. Also > what's the solution then. The solution is to just fstat the files and verify the filesystem from which they came after the files have been opened. The issue is that an evil root user may have mounted something else on /proc. >> I believe glibc has some code which triggers for suid root applications >> that we should ensure gets triggered that avoid trusting things like >> LD_LIBRARY_PATH and company. > > I guess linking statically with uClibc or klibc (as hpa said), might turn > out to be better option to avoid all the issues w.r.t shared objects > and all the tricky environment variables. Linking with a more restricted libc will solve most if not all shared object issues. We still need to audit our environment variable issue. How we interpret them and how our restricted libc automatically interprets them. Eric
