linux-kernel - Re: [PATCH 07/11] kexec: Disable in a secure boot environment

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: <87r4qhwkx9.fsf@xmission.com>
Date:	Tue, 04 Sep 2012 14:13:54 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [PATCH 07/11] kexec: Disable in a secure boot environment

Matthew Garrett <mjg59@...f.ucam.org> writes:

> On Tue, Sep 04, 2012 at 01:13:32PM -0700, Eric W. Biederman wrote:
>> 
>> Matthew Garrett <mjg@...hat.com> writes:
>> 
>> > kexec could be used as a vector for a malicious user to use a signed kernel
>> > to circumvent the secure boot trust model. In the long run we'll want to
>> > support signed kexec payloads, but for the moment we should just disable
>> > loading entirely in that situation.
>> 
>> Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>> 
>> This makes no sense.  The naming CAP_SECURE_FIRMWARE is attrocious,
>> you aren't implementing or enforcing secure firmware.
>
> I'm certainly not attached to the name, and have no problem replacing 
> it.
>
>> You don't give any justification for this other than to support some
>> silly EFI feature.  Why would anyone want this if we were not booting
>> under EFI?
>
> Well, given that approximately everyone will be booting under EFI within 
> 18 months, treating it as a niche case seems a little short sighted.

If we are all going to be using the code we need to keep the code
quality high.

> And 
> secondly, there are already several non-EFI platforms that want to enact 
> a policy preventing root from being able to arbitrarily replace the 
> kernel. Given that people are doing this in the wild, it makes sense to 
> move towards offering that policy in the mainline kernel.

Either this code makes sense without an appeal to EFI or this code makes
no sense.

It is fine for jumping through the EFI trusted boot hoops to be your
motivation, but EFI policy should not be the justification for kernel
implementation details.

There may be some sense to the desired functionality.  From what I have
seen of the policies so far I have no respect for the way people are
using EFI secure boot.  I have no expectation that EFI secure boot will
stop malware as long as anything signed by microsoft's key is trusted by
the firmware.  We have already seen malware in the wild that could be
verified with Microsoft's key.

So please rework this to come from an angle that makes sense all by
itself.

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/