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]
Date:   Thu, 5 Apr 2018 09:45:21 +0800
From:   joeyli <>
To:     Andy Lutomirski <>
Cc:     Greg Kroah-Hartman <>,
        "Theodore Y. Ts'o" <>,
        Matthew Garrett <>,
        Linus Torvalds <>,
        David Howells <>,
        Ard Biesheuvel <>,
        James Morris <>,
        Alan Cox <>,
        Linux Kernel Mailing List <>,
        Justin Forbes <>,
        linux-man <>,
        LSM List <>,
        Linux API <>,
        Kees Cook <>,
        linux-efi <>
Subject: Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure

Hi Andy,

On Wed, Apr 04, 2018 at 07:49:12AM -0700, Andy Lutomirski wrote:
> Since this thread has devolved horribly, I'm going to propose a solution.
> 6. There's a way to *decrease* the lockdown level below the configured
> value.  (This ability itself may be gated by a config option.)
> Choices include a UEFI protected variable, an authenticated flag
> passed by the bootloader, and even just some special flag in the boot
> handoff protocol.  It would be really quite useful for a user to be
> able to ask their bootloader to reduce the lockdown level for the
> purpose of a particular boot for debugging.  I read the docs on

The "mokutil --disable-validation" done a similar bahvior as above.
Just it lets kernel to ignore the secure boot. 

> mokutil --disable-validation, and it's quite messy.  Let's have a way
> to do this that is mostly independent of the particular firmware in
> use.

Why the disabl-validation is messy?   
The mokutil is shim specific but not dependent on particular firmware. 
> I can imagine a grub option that decreases lockdown level along with a
> rule that grub will *not* load that option from its config, for
> example.

The root can modify the grub config to decrease lockdown level in next
boot without physcial accessing. The mokutil's interactive UI is used
to deal with user to confirm the physcial accessing.

Joey Lee

Powered by blists - more mailing lists