Re: Kdump with signed images

From: ebiederm@xmission.com (Eric W. Biederman)
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Matthew Garrett <mjg@redhat.com>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Khalid Aziz <khalid@gonehiking.org>,
	kexec@lists.infradead.org, horms@verge.net.au,
	Dave Young <dyoung@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Dmitry Kasatkin <dmitry.kasatkin@intel.com>,
	Roberto Sassu <roberto.sassu@polito.it>,
	Kees Cook <keescook@chromium.org>,
	Peter Jones <pjones@redhat.com>
Subject: Re: Kdump with signed images
Date: Mon, 05 Nov 2012 11:44:48 -0800	[thread overview]
Message-ID: <87mwyv96mn.fsf@xmission.com> (raw)
In-Reply-To: <20121105180353.GC28720@redhat.com> (Vivek Goyal's message of "Mon, 5 Nov 2012 13:03:53 -0500")

Vivek Goyal <vgoyal@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