An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)
jlee at suse.com
Thu Apr 5 01:45:21 UTC 2018
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
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
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.
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Linux-security-module-archive