linux-kernel - Re: [PATCH 0/5] security, efi: Set lockdown if in secure boot mode

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: <CAKv+Gu96h=isM7_-niVmw0pojonD5Sr9Z_onqmkb22GVdH4NVA@mail.gmail.com>
Date:   Fri, 9 Jun 2017 17:33:26 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     David Howells <dhowells@...hat.com>,
        Kees Cook <keescook@...omium.org>
Cc:     Matthew Garrett <matthew.garrett@...ula.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/5] security, efi: Set lockdown if in secure boot mode

(+ Kees)

On 6 June 2017 at 09:34, David Howells <dhowells@...hat.com> wrote:
> Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:
>
>> and print a subsequent line for every lockdown feature that is enabled, e.g.,
>>
>> lockdown: disabling MSRs
>> lockdown: disabling hibernate support
>
> There's another problem with this idea: the lockdown facility is passive - it
> doesn't go looking for things to lock down; rather, things that can be locked
> down inquire as to whether lockdown is in effect at the point someone tries to
> use them.
>
> Now, I could reserve a variable for each thing we lock down to make sure that
> we don't emit the message more than once, but I'm loathe to waste memory this
> way.
>
> I can't so easily switch the facility to being active either, since a lot of
> the lockdownables are in modules.
>

Let me reiterate my concern for Kees's sake: without a threat model
nor any notion of how much kernel lockdown reduces the attack surface,
we end up with a 'doing something is better than nothing' approach.
Fine. But now you are telling me that there is no way we can provide
information to the user what that 'something' amounts to for a
particular kernel build for a particular architecture. Do you intend
to add lockdown features going forward after enabling the initial set?
Would any of these lockdown features ever be Kconfigurable? Do you
expect all lockdown features to be applicable to all architectures? So
how do I know what lockdown actually means for my system?

Anyway, I think I have made my concerns clear, and the EFI bits look
fine to me as long as the policy lives elsewhere.

Apologies for letting this drag on a bit. I do agree in principle, but
I'd like to get the details right as well.

Thanks,
Ard.