linux-kernel - Re: kexec_load(2) bypasses signature verification

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]

Message-ID: <CA+5PVA6YKR_=uVpM2rW4et3YCJLh9c+uuxt2koH1Fy2ZuR7W-g@mail.gmail.com>
Date:	Mon, 15 Jun 2015 09:37:05 -0400
From:	Josh Boyer <jwboyer@...oraproject.org>
To:	"Theodore Ts'o" <tytso@....edu>,
	Eric Biederman <ebiederm@...ssion.com>,
	David Howells <dhowells@...hat.com>,
	kexec <kexec@...ts.infradead.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: kexec_load(2) bypasses signature verification

On Mon, Jun 15, 2015 at 9:17 AM, Theodore Ts'o <tytso@....edu> wrote:
> On Mon, Jun 15, 2015 at 08:14:19AM -0400, Josh Boyer wrote:
>> Yes, which is why most of the distro vendors carry an out-of-tree
>> patch that disables the old kexec in an SB setup.  It would be nice if
>> we could merge said patches.  However, they depend on Matthew's
>> secure_modules/trusted_kernel/<whatever name that works> patchset
>> which has gotten little movement since we came up with a tentative
>> agreement at LPC 2013.
>
> Signed modules is in, though, right?  And the fact that we have

Yes.

> CONFIG_SIGNED_PE_FILE_VERIFICATION means we're doing unatural file
> signatures w/o using ELF, which I thought was the basis of Linus's
> accusation that Red Hat was performing intimate/physical acts with
> Microsoft.  :-)
>
> I would have thought those were the nasty bits to get in; out of
> curiosity, what's still missing?

The bits that actually read Secure Boot state out of the UEFI
variables, and apply protections to the machine to avoid compromise
under the SB threat model.  Things like disabling the old kexec,
enforcing module signatures at runtime, restricting various access
(like /dev/mem, /dev/kmem), adding certs in UEFI db to the system
keyring, and enforcing the UEFI dbx blacklist.  So most of the patches
in Matthew's set relate to enforcement using the bits of functionality
already merged.  They aren't even strictly tied to UEFI or SB, but
some of the other patches distos carry are.  We had tentative
agreement even from Linus on much of this (his words were along the
lines of "create a flag and use the flag"), but it's failed to
actually get carried in any tree for a few reasons.

josh
--
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/