linux-kernel - Re: Kdump with signed images

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 05 Nov 2012 11:44:48 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Matthew Garrett <mjg@...hat.com>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Khalid Aziz <khalid@...ehiking.org>, kexec@...ts.infradead.org,
	horms@...ge.net.au, Dave Young <dyoung@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Dmitry Kasatkin <dmitry.kasatkin@...el.com>,
	Roberto Sassu <roberto.sassu@...ito.it>,
	Kees Cook <keescook@...omium.org>,
	Peter Jones <pjones@...hat.com>
Subject: Re: Kdump with signed images

Vivek Goyal <vgoyal@...hat.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/