linux-kernel - Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi

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>] [day] [month] [year] [list]

Message-ID: <20121025153937.GE9377@redhat.com>
Date:	Thu, 25 Oct 2012 11:39:37 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Matthew Garrett <mjg@...hat.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.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>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
Subject: Re: [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass
 acpi_rsdp= to 2nd kernel for efi booting)

On Tue, Oct 23, 2012 at 04:41:24PM +0100, Matthew Garrett wrote:
> On Tue, Oct 23, 2012 at 10:59:20AM -0400, Vivek Goyal wrote:
> 
> > But what about creation of a new program which can call kexec_load()
> > and execute an unsigned kernel. Doesn't look like that will be
> > prevented using IMA.
> 
> Right. Trusting userspace would require a new system call that passes in 
> a signature of the userspace binary, and the kernel would then have to 
> verify the ELF object in memory in order to ensure that it 
> matches the signature.

[ CC lkml and IMA/EVM developers ]

Not sure how much of this is feasible. There is initialized data which
can change. That means we shall have to exclude initialized data from
digest. And then initialized data can be changed by attacker.

I think in the context of kexec, purgatory (which is actually a
relocatable executable), is embedded in kexec binary as "const char
purgatory[]". I am assuming that it will show up as initialized data
in /sbin/kexec. And if we do not include initialized data in digest
calculation, then one can overwrite purgatory with its own executable
code and kexec will load it into the kernel and let it run at priviliged
level.

So looks like even above will not be foolproof. (Assuming we can do
this. I thought we lost all the elf headers after loading elf 
binary and now we don't know which mmpaed areas need to be included
in digest and which should not be).

> Verifying that the copy on the filesystem is 
> unmodified isn't adequate - an attacker could simply have paused the 
> process and injected code.

This is an interesting point. So even if we verify the signature of
/sbin/kexec, parent can change the code (using ptrace() interface?).
And we are again prone to attack. So this will work if we are doing
integrity/authenticity checks on all root processes and not just
one /sbin/kexec.

> Realistically, the only solution here is for 
> the kernel to verify that the kernel it's about to boot is signed and 
> for it not to take any untrusted executable code from userspace.

Hmm.., given above, looks like implementing a new system call to pass
in full kernel and initramfs (along with some command line or other
parameters), becomes interesting.

Thanks
Vivek
--
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/