lkml.org 
[lkml]   [2018]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [GIT PULL] Kernel lockdown for secure boot
    On Tue, Apr 3, 2018 at 4:26 PM Linus Torvalds
    <torvalds@linux-foundation.org>
    wrote:

    > On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett <mjg59@google.com> wrote:
    > >
    > > 1) Secure Boot is intended to permit the construction of a boot chain
    that
    > > only runs ring 0 code that the user considers trustworthy

    > No.

    > That may be *one* intention, for some people.

    > It's not an a-priori one for the actual user.

    Secure Boot is intended to *permit* that. Without Secure Boot you're unable
    to do that. Some users want that. Some users don't.

    > > 2) Allowing arbitrary user code to run in ring 0 without affirmative
    > > consent on the part of the user is therefore incompatible with the
    goals of
    > > Secure Boot

    > Again, that has absolutely zero relevance.

    > Those goals are not the *users* goals.

    > Be honest now. It wasn't generally users who clamored for it.

    If you ask a user whether they want a system that lets an attacker replace
    their kernel or one that doesn't, what do you think their answer is likely
    to be?

    > If the user actually wanted it, and is asking for it, he can enable
    > it. Independently of secure boot, which the user generally has little
    > control over.

    How? If the bootloader will boot kernels that don't impose this restriction
    then an attacker just replaces whatever's enabling that feature. And, uh,
    seriously, I've been asking for *years* for someone to point me at a PC on
    the market that doesn't give the user control over Secure Boot, but Shim
    was expressly designed to ensure that the user would have the ability to
    enroll additional trusted keys (or disable signature validation entirely),
    so which cases are you thinking of where the user doesn't have control?

    > > 3) This patchset provides a mechanism to alter the behaviour of the
    kernel
    > > such that it is significantly more difficult for arbitrary user code to
    run
    > > in ring 0 without affirmative user consent

    > That difficulty already exists, the new thing isn't somehow related to
    > that at all.

    > Look at our "uyou can only load modules if you're root" rules. Or the
    > "you can only load modules if they are signed".

    > See a pattern there? They don't magically enable themselves (or
    > disable themselves) depending on whether you booted with secure boot
    > or not.

    What's the benefit of "You can only load modules if they are signed" if
    root is able to just overwrite that policy bit in the kernel? The split
    between unprivileged users and root is real, but right now module
    signatures are theater - there's no significant security benefit from them.
    But the reason to tie this to Secure Boot is that without that an attacker
    who has root can just replace the kernel on disk (or patch the bootloader
    to live-patch the kernel on boot, and yes that's an attack we've seen in
    the real world), so while it's a feature that is arguably beneficial under
    all circumstances it's a feature that only has significant benefit if you
    have some way to actually validate what you're booting in the first place.

    > > 4) Providing a mechanism for automatically enabling this behaviour when
    > > running in a context that is intended to restrict access to ring 0 is a
    > > rational thing to do, because otherwise it is difficult to achieve the
    > > objective in (1)

    > No. See why it's *NOT* rational, as explained already several times.

    > Magically changing kernel behavior depending on some subtle and often
    > unintentional bootup behavior detail is completely idiotic.

    > It would be idiotic if it was that "check kernel module signatures"
    > check. This is no less idiotic.

    > Seriously, listen to your own arguments. If they don't make sense for
    > checking kernel module signatures, why the hell would they make sense
    > for something like lockdown.

    > THE TWO THINGS ARE ENTIRELY INDEPENDENT.

    Again, what is your proposed mechanism for ensuring that off the shelf
    systems can be configured in a way that makes this possible?

    \
     
     \ /
      Last update: 2018-04-04 01:46    [W:4.367 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site