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: <379.1496237632@warthog.procyon.org.uk>
Date:   Wed, 31 May 2017 14:33:52 +0100
From:   David Howells <dhowells@...hat.com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     dhowells@...hat.com, 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

Ard Biesheuvel <ard.biesheuvel@...aro.org> wrote:

> No, I am fine with keeping this as a single series. I don't want
> anything under drivers/efi to imply policy regarding lockdown. Kernel
> lockdown should be a feature that lives somewhere else, and which
> contains a CONFIG_ option that implies 'lockdown is enabled by default
> when UEFI secure boot is detected.' The code that gets added to
> drivers/efi should only concern itself with establishing whether
> secure boot is in effect or not (and can hence be enabled
> unconditionally)
> ...
> So what I would prefer is to separate this from the EFI code,

In that case I don't know where to connect the UEFI secure boot with the
lockdown code.

I was under the impression that you wanted the switch-statement that I had in
x86 setup.c moved to the efi code (as I've done in patch 1).  Was I wrong in
that assessment and that you actually wanted it, say, in security?

I don't think that the non-EFI core code should know about UEFI secure boot
mode.  Either the arch needs to implement the connection or the EFI code needs
to implement it.  In the former is preferred, I should drop patch 1.

> ... and perhaps print something like
> 
> lockdown: Kernel lockdown policy in effect due to xxx

I'm okay with printing that instead.

> and print a subsequent line for every lockdown feature that is enabled, e.g.,
> 
> lockdown: disabling MSRs
> lockdown: disabling hibernate support

That could add a lot of lines to the boot output:-/

David

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ