From: David Howells <dhowells@redhat.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: dhowells@redhat.com, Matthew Garrett <mjg59@google.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
James Morris <jmorris@namei.org>,
Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Justin Forbes <jforbes@redhat.com>,
linux-man <linux-man@vger.kernel.org>, joeyli <jlee@suse.com>,
LSM List <linux-security-module@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Kees Cook <keescook@chromium.org>,
linux-efi <linux-efi@vger.kernel.org>
Subject: Re: [GIT PULL] Kernel lockdown for secure boot
Date: Wed, 04 Apr 2018 00:12:59 +0100 [thread overview]
Message-ID: <10232.1522797179@warthog.procyon.org.uk> (raw)
In-Reply-To: <CALCETrV6E+r942K+fu-ALNf-x6qOZ3o1hNKGeu7qEMvr8sMP9A@mail.gmail.com>
Andy Lutomirski <luto@kernel.org> wrote:
> I'm having a very, very hard time coming up with a scenario where I
> can "trust" something if an attacker can get root but can't modify the
> running kernel image but I can't "trust" something if the attacker
> can [modify the running kernel image].
(I think the above is what you meant)
Let's go at this a different way. How do you decide you can trust something
in this context? You compare it to something. Signing it, keeping a hash
whitelist, IMA - these are all ways of comparing something. Do you agree with
that?
However, the comparison can be subverted if the running kernel image (I might
be better saying running kernel state here since I'm not talking about the
source bzImage file) can be modified arbitrarily by userspace, either by
modifying the data against which the comparison is made - e.g. the public key
set or the hash list - or by modifying the code that makes the comparison.
/dev/mem, direct access to DMA, bpf, etc. all provide ways of modifying the
kernel image arbitrarily, which leads me to this:
> I *don't* buy into the party line about why signed modules should be needed
> for Secure Boot.
Modules are just another way of modifying the kernel image. If I can just
create an arbitrary module and load it, then I can modify the kernel image
from within the module.
Locking down modules by signing, hashing or IMA practically prevents the
loading of arbitrarily constructed modules and only permits modules from a set
that the provider of the modules somewhat trusts.
What use is secure boot if processes run as root can subvert your kernel?
> > There's no point bothering with UID/GID checking either.
>
> Give me a break. There's a *huge* difference between a system where
> only root can load unsigned modules and a system where anyone can load
> unsigned modules.
I don't think we've ever advocated letting just anyone load a module.
But my point is that if you can modify the running kernel, you can nullify all
security checks, including UID/GID checks.
> > However, if /dev/mem can be read, any root process can extract the session
> > key for your disk.
>
> Any root process can read /dev/mapper/plaintext_disk, lockdown or otherwise.
True - for now - and they can also access the mounted filesystem. But if they
get their hands on your powered-off computer, no, they can't.
> But I don't think the upstream kernel should apply a patch that ties any of
> this to Secure Boot without a genuine technical reason why it makes sense.
Because unless you turn lockdown on during kernel boot, there exists a window
of opportunity where the kernel isn't locked down and can be accessed, thereby
obviating the fact that you started in Secure Boot mode.
David
WARNING: multiple messages have this Message-ID (diff)
From: dhowells@redhat.com (David Howells)
To: linux-security-module@vger.kernel.org
Subject: [GIT PULL] Kernel lockdown for secure boot
Date: Wed, 04 Apr 2018 00:12:59 +0100 [thread overview]
Message-ID: <10232.1522797179@warthog.procyon.org.uk> (raw)
In-Reply-To: <CALCETrV6E+r942K+fu-ALNf-x6qOZ3o1hNKGeu7qEMvr8sMP9A@mail.gmail.com>
Andy Lutomirski <luto@kernel.org> wrote:
> I'm having a very, very hard time coming up with a scenario where I
> can "trust" something if an attacker can get root but can't modify the
> running kernel image but I can't "trust" something if the attacker
> can [modify the running kernel image].
(I think the above is what you meant)
Let's go at this a different way. How do you decide you can trust something
in this context? You compare it to something. Signing it, keeping a hash
whitelist, IMA - these are all ways of comparing something. Do you agree with
that?
However, the comparison can be subverted if the running kernel image (I might
be better saying running kernel state here since I'm not talking about the
source bzImage file) can be modified arbitrarily by userspace, either by
modifying the data against which the comparison is made - e.g. the public key
set or the hash list - or by modifying the code that makes the comparison.
/dev/mem, direct access to DMA, bpf, etc. all provide ways of modifying the
kernel image arbitrarily, which leads me to this:
> I *don't* buy into the party line about why signed modules should be needed
> for Secure Boot.
Modules are just another way of modifying the kernel image. If I can just
create an arbitrary module and load it, then I can modify the kernel image
from within the module.
Locking down modules by signing, hashing or IMA practically prevents the
loading of arbitrarily constructed modules and only permits modules from a set
that the provider of the modules somewhat trusts.
What use is secure boot if processes run as root can subvert your kernel?
> > There's no point bothering with UID/GID checking either.
>
> Give me a break. There's a *huge* difference between a system where
> only root can load unsigned modules and a system where anyone can load
> unsigned modules.
I don't think we've ever advocated letting just anyone load a module.
But my point is that if you can modify the running kernel, you can nullify all
security checks, including UID/GID checks.
> > However, if /dev/mem can be read, any root process can extract the session
> > key for your disk.
>
> Any root process can read /dev/mapper/plaintext_disk, lockdown or otherwise.
True - for now - and they can also access the mounted filesystem. But if they
get their hands on your powered-off computer, no, they can't.
> But I don't think the upstream kernel should apply a patch that ties any of
> this to Secure Boot without a genuine technical reason why it makes sense.
Because unless you turn lockdown on during kernel boot, there exists a window
of opportunity where the kernel isn't locked down and can be accessed, thereby
obviating the fact that you started in Secure Boot mode.
David
--
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
next prev parent reply other threads:[~2018-04-03 23:13 UTC|newest]
Thread overview: 252+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-30 23:29 [GIT PULL] Kernel lockdown for secure boot David Howells
2018-03-30 23:29 ` David Howells
2018-03-31 0:46 ` James Morris
2018-03-31 0:46 ` James Morris
2018-04-03 0:37 ` Andy Lutomirski
2018-04-03 0:37 ` Andy Lutomirski
2018-04-03 0:59 ` Kees Cook
2018-04-03 0:59 ` Kees Cook
2018-04-03 1:47 ` Andy Lutomirski
2018-04-03 1:47 ` Andy Lutomirski
2018-04-03 7:06 ` David Howells
2018-04-03 7:06 ` David Howells
2018-04-03 15:11 ` Andy Lutomirski
2018-04-03 15:11 ` Andy Lutomirski
2018-04-03 15:41 ` Alexei Starovoitov
2018-04-03 15:41 ` Alexei Starovoitov
2018-04-03 16:26 ` Andy Lutomirski
2018-04-03 16:26 ` Andy Lutomirski
2018-04-03 16:29 ` Matthew Garrett
2018-04-03 16:29 ` Matthew Garrett
2018-04-03 16:45 ` Andy Lutomirski
2018-04-03 16:45 ` Andy Lutomirski
2018-04-03 18:45 ` Kees Cook
2018-04-03 18:45 ` Kees Cook
2018-04-03 19:01 ` Andy Lutomirski
2018-04-03 19:01 ` Andy Lutomirski
2018-04-03 19:07 ` Kees Cook
2018-04-03 19:07 ` Kees Cook
2018-04-03 19:29 ` Matthew Garrett
2018-04-03 19:29 ` Matthew Garrett
2018-04-03 21:51 ` Andy Lutomirski
2018-04-03 21:51 ` Andy Lutomirski
2018-04-04 18:42 ` Peter Jones
2018-04-04 18:42 ` Peter Jones
2018-04-04 20:01 ` Thomas Gleixner
2018-04-04 20:01 ` Thomas Gleixner
2018-04-04 20:18 ` Matthew Garrett
2018-04-04 20:18 ` Matthew Garrett
2018-04-05 18:47 ` Andy Lutomirski
2018-04-05 18:47 ` Andy Lutomirski
2018-04-06 4:42 ` Peter Dolding
2018-04-06 4:42 ` Peter Dolding
2018-04-03 17:16 ` David Howells
2018-04-03 17:16 ` David Howells
2018-04-03 19:01 ` Andy Lutomirski
2018-04-03 19:01 ` Andy Lutomirski
2018-04-03 19:49 ` David Howells
2018-04-03 19:49 ` David Howells
2018-04-03 21:58 ` Andy Lutomirski
2018-04-03 21:58 ` Andy Lutomirski
2018-04-03 22:32 ` David Howells
2018-04-03 22:32 ` David Howells
2018-04-03 22:39 ` Andy Lutomirski
2018-04-03 22:39 ` Andy Lutomirski
2018-04-03 22:46 ` Linus Torvalds
2018-04-03 22:46 ` Linus Torvalds
2018-04-03 22:51 ` Matthew Garrett
2018-04-03 22:51 ` Matthew Garrett
2018-04-03 22:53 ` Andy Lutomirski
2018-04-03 22:53 ` Andy Lutomirski
2018-04-03 23:08 ` Justin Forbes
2018-04-03 23:09 ` Matthew Garrett
2018-04-03 23:09 ` Matthew Garrett
2018-04-03 23:08 ` Linus Torvalds
2018-04-03 23:08 ` Linus Torvalds
2018-04-03 23:10 ` Linus Torvalds
2018-04-03 23:10 ` Linus Torvalds
2018-04-03 23:17 ` Matthew Garrett
2018-04-03 23:17 ` Matthew Garrett
2018-04-03 23:26 ` Linus Torvalds
2018-04-03 23:26 ` Linus Torvalds
2018-04-03 23:39 ` Linus Torvalds
2018-04-03 23:39 ` Linus Torvalds
2018-04-03 23:47 ` Matthew Garrett
2018-04-03 23:47 ` Matthew Garrett
2018-04-04 0:02 ` Linus Torvalds
2018-04-04 0:02 ` Linus Torvalds
2018-04-04 0:04 ` Matthew Garrett
2018-04-04 0:04 ` Matthew Garrett
2018-04-04 0:08 ` Linus Torvalds
2018-04-04 0:08 ` Linus Torvalds
2018-04-04 0:12 ` Matthew Garrett
2018-04-04 0:12 ` Matthew Garrett
2018-04-05 14:58 ` Alan Cox
2018-04-05 14:58 ` Alan Cox
2018-04-04 0:22 ` David Howells
2018-04-04 0:22 ` David Howells
2018-04-04 0:22 ` David Howells
2018-04-05 17:59 ` Alan Cox
2018-04-05 17:59 ` Alan Cox
2018-04-05 18:03 ` Matthew Garrett
2018-04-05 18:03 ` Matthew Garrett
2018-04-03 23:45 ` Matthew Garrett
2018-04-03 23:45 ` Matthew Garrett
2018-04-03 23:55 ` Linus Torvalds
2018-04-03 23:55 ` Linus Torvalds
2018-04-03 23:59 ` Matthew Garrett
2018-04-03 23:59 ` Matthew Garrett
2018-04-04 0:06 ` Linus Torvalds
2018-04-04 0:06 ` Linus Torvalds
2018-04-04 0:10 ` Matthew Garrett
2018-04-04 0:10 ` Matthew Garrett
2018-04-04 0:15 ` Linus Torvalds
2018-04-04 0:15 ` Linus Torvalds
2018-04-04 0:16 ` Matthew Garrett
2018-04-04 0:16 ` Matthew Garrett
2018-04-04 0:18 ` Andy Lutomirski
2018-04-04 0:18 ` Andy Lutomirski
2018-04-04 0:19 ` Matthew Garrett
2018-04-04 0:19 ` Matthew Garrett
2018-04-04 9:04 ` Greg Kroah-Hartman
2018-04-04 9:04 ` Greg Kroah-Hartman
2018-04-04 0:25 ` Linus Torvalds
2018-04-04 0:25 ` Linus Torvalds
2018-04-04 0:33 ` Linus Torvalds
2018-04-04 0:33 ` Linus Torvalds
2018-04-04 0:46 ` Matthew Garrett
2018-04-04 0:46 ` Matthew Garrett
2018-04-04 0:56 ` Linus Torvalds
2018-04-04 0:56 ` Linus Torvalds
2018-04-04 1:13 ` Matthew Garrett
2018-04-04 1:13 ` Matthew Garrett
2018-04-04 1:43 ` Linus Torvalds
2018-04-04 1:43 ` Linus Torvalds
2018-04-04 4:30 ` Matthew Garrett
2018-04-04 4:30 ` Matthew Garrett
2018-04-04 12:57 ` Theodore Y. Ts'o
2018-04-04 12:57 ` Theodore Y. Ts'o
2018-04-04 13:02 ` Greg Kroah-Hartman
2018-04-04 13:02 ` Greg Kroah-Hartman
2018-04-04 13:34 ` Theodore Y. Ts'o
2018-04-04 13:34 ` Theodore Y. Ts'o
2018-04-04 13:57 ` Greg Kroah-Hartman
2018-04-04 13:57 ` Greg Kroah-Hartman
2018-04-04 13:29 ` Mike Galbraith
2018-04-04 13:29 ` Mike Galbraith
2018-04-04 16:20 ` Matthew Garrett
2018-04-04 16:20 ` Matthew Garrett
2018-04-08 22:00 ` Pavel Machek
2018-04-04 13:33 ` David Howells
2018-04-04 13:33 ` David Howells
2018-04-04 13:52 ` Theodore Y. Ts'o
2018-04-04 13:52 ` Theodore Y. Ts'o
2018-04-04 16:22 ` Matthew Garrett
2018-04-04 16:22 ` Matthew Garrett
2018-04-04 16:39 ` Andy Lutomirski
2018-04-04 16:39 ` Andy Lutomirski
2018-04-04 16:42 ` Matthew Garrett
2018-04-04 16:42 ` Matthew Garrett
2018-04-04 16:46 ` Justin Forbes
2018-04-04 16:46 ` Justin Forbes
2018-04-05 0:05 ` Peter Dolding
2018-04-05 0:05 ` Peter Dolding
2018-04-05 0:20 ` Matthew Garrett
2018-04-05 0:20 ` Matthew Garrett
2018-04-04 13:57 ` David Howells
2018-04-04 13:57 ` David Howells
2018-04-04 16:09 ` Linus Torvalds
2018-04-04 16:09 ` Linus Torvalds
2018-04-04 16:17 ` Matthew Garrett
2018-04-04 16:17 ` Matthew Garrett
2018-04-04 6:56 ` Peter Dolding
2018-04-04 6:56 ` Peter Dolding
2018-04-04 16:26 ` Matthew Garrett
2018-04-04 16:26 ` Matthew Garrett
2018-04-05 1:28 ` Peter Dolding
2018-04-05 1:28 ` Peter Dolding
2018-04-04 1:30 ` Justin Forbes
2018-04-04 1:58 ` Linus Torvalds
2018-04-04 1:58 ` Linus Torvalds
2018-04-04 1:36 ` Justin Forbes
2018-04-04 1:36 ` Justin Forbes
2018-04-04 0:17 ` Jann Horn
2018-04-04 0:17 ` Jann Horn
2018-04-04 0:23 ` Andy Lutomirski
2018-04-04 0:23 ` Andy Lutomirski
2018-04-04 8:05 ` David Howells
2018-04-04 8:05 ` David Howells
2018-04-04 8:05 ` David Howells
2018-04-04 14:35 ` Andy Lutomirski
2018-04-04 14:35 ` Andy Lutomirski
2018-04-04 14:44 ` David Howells
2018-04-04 14:44 ` David Howells
2018-04-04 14:44 ` David Howells
2018-04-04 15:43 ` Eric W. Biederman
2018-04-04 15:43 ` Eric W. Biederman
2018-04-03 23:56 ` David Howells
2018-04-03 23:56 ` David Howells
2018-04-03 23:56 ` David Howells
2018-04-03 23:58 ` Linus Torvalds
2018-04-03 23:58 ` Linus Torvalds
2018-04-03 23:39 ` David Howells
2018-04-03 23:39 ` David Howells
2018-04-03 23:48 ` Andy Lutomirski
2018-04-03 23:48 ` Andy Lutomirski
2018-04-08 8:23 ` Pavel Machek
2018-04-03 23:12 ` David Howells [this message]
2018-04-03 23:12 ` David Howells
2018-04-03 23:27 ` Linus Torvalds
2018-04-03 23:27 ` Linus Torvalds
2018-04-03 23:42 ` Andy Lutomirski
2018-04-03 23:42 ` Andy Lutomirski
2018-04-03 20:53 ` Linus Torvalds
2018-04-03 20:53 ` Linus Torvalds
2018-04-03 20:54 ` Matthew Garrett
2018-04-03 20:54 ` Matthew Garrett
2018-04-03 21:01 ` Linus Torvalds
2018-04-03 21:01 ` Linus Torvalds
2018-04-03 21:08 ` Matthew Garrett
2018-04-03 21:08 ` Matthew Garrett
2018-04-03 21:21 ` Al Viro
2018-04-03 21:21 ` Al Viro
2018-04-03 21:37 ` Matthew Garrett
2018-04-03 21:37 ` Matthew Garrett
2018-04-03 21:26 ` Linus Torvalds
2018-04-03 21:26 ` Linus Torvalds
2018-04-03 21:32 ` Matthew Garrett
2018-04-03 21:32 ` Matthew Garrett
2018-04-08 8:10 ` Pavel Machek
2018-03-31 10:20 ` David Howells
2018-03-31 10:20 ` David Howells
2018-04-03 13:25 ` Ard Biesheuvel
2018-04-03 13:25 ` Ard Biesheuvel
2018-04-03 21:48 ` James Morris
2018-04-03 21:48 ` James Morris
2018-04-05 17:53 ` Alan Cox
2018-04-05 17:53 ` Alan Cox
2018-11-21 12:05 ` [PATCH next-lockdown 0/1] debugfs EPERM fix for 'Kernel lockdown for secure boot' patch series Vasily Gorbik
2018-11-21 12:05 ` [PATCH next-lockdown 1/1] debugfs: avoid EPERM when no open file operation defined Vasily Gorbik
-- strict thread matches above, loose matches on Subject: below --
2018-04-04 2:34 [GIT PULL] Kernel lockdown for secure boot Alexei Starovoitov
2018-04-04 2:34 ` Alexei Starovoitov
2018-04-04 4:31 ` Matthew Garrett
2018-04-04 4:31 ` Matthew Garrett
2018-04-08 7:44 ` joeyli
2018-04-08 7:44 ` joeyli
2018-04-08 8:07 ` joeyli
2018-04-08 8:07 ` joeyli
2018-04-09 3:40 ` Alexei Starovoitov
2018-04-09 3:40 ` Alexei Starovoitov
2018-04-09 8:14 ` Daniel Borkmann
2018-04-09 8:14 ` Daniel Borkmann
2018-04-09 13:55 ` joeyli
2018-04-09 13:55 ` joeyli
2017-10-26 16:37 David Howells
2017-10-26 16:37 ` David Howells
2017-10-26 16:37 ` David Howells
2017-10-26 18:22 ` Mimi Zohar
2017-10-26 18:22 ` Mimi Zohar
2017-10-26 18:22 ` Mimi Zohar
2017-10-26 19:20 ` James Morris
2017-10-26 19:20 ` James Morris
2017-10-26 19:20 ` James Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10232.1522797179@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=ard.biesheuvel@linaro.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=jforbes@redhat.com \
--cc=jlee@suse.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mjg59@google.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.