* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-03 21:01 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes,
linux-man, jlee, LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CACdnJuuXOP5T-BRAwMvc7XF8S49wyvp4ZYgcU=EZkaGNgPAQig@mail.gmail.com>
On Tue, Apr 3, 2018 at 1:54 PM, Matthew Garrett <mjg59@google.com> wrote:
>
>> .. maybe you don't *want* secure boot, but it's been pushed in your
>> face by people with an agenda?
>
> Then turn it off, or build a self-signed kernel that doesn't do this?
Umm. So you asked a question, and then when you got an answer you said
"don't do that then".
The fact is, some hardware pushes secure boot pretty hard. That has
*nothing* to do with some "lockdown" mode.
Why do you conflate the two? That was the original question. You
replied with another question. People answered yours.
NOW ANSWER THE ORIGINAL QUESTION, DAMMIT.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-03 21:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFzGFZT68ih446DeQbB69Fyk_wT6b7PGq0iz-gctUGQq_A@mail.gmail.com>
On Tue, Apr 3, 2018 at 2:01 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> On Tue, Apr 3, 2018 at 1:54 PM, Matthew Garrett <mjg59@google.com> wrote:
> >
> >> .. maybe you don't *want* secure boot, but it's been pushed in your
> >> face by people with an agenda?
> >
> > Then turn it off, or build a self-signed kernel that doesn't do this?
> Umm. So you asked a question, and then when you got an answer you said
> "don't do that then".
> The fact is, some hardware pushes secure boot pretty hard. That has
> *nothing* to do with some "lockdown" mode.
Secure Boot ensures that the firmware will only load signed bootloaders. If
a signed bootloader loads a kernel that's effectively an unsigned
bootloader, there's no point in using Secure Boot - you should just turn it
off instead, because it's not giving you any meaningful security. Andy's
example gives a scenario where by constraining your *userland* sufficiently
you can get close to having the same guarantees, but that involves you
having a read-only filesystem and takes you even further away from having a
general purpose computer.
If you don't want Secure Boot, turn it off. If you want Secure Boot, use a
kernel that behaves in a way that actually increases your security.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Al Viro @ 2018-04-03 21:21 UTC (permalink / raw)
To: Matthew Garrett
Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes,
linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CACdnJuvheCbuvTLyDWMQWcUytc4EvuSUaEKywfEX8Kp6qYL9dg@mail.gmail.com>
On Tue, Apr 03, 2018 at 09:08:54PM +0000, Matthew Garrett wrote:
> > The fact is, some hardware pushes secure boot pretty hard. That has
> > *nothing* to do with some "lockdown" mode.
>
> Secure Boot ensures that the firmware will only load signed bootloaders. If
> a signed bootloader loads a kernel that's effectively an unsigned
> bootloader, there's no point in using Secure Boot - you should just turn it
> off instead, because it's not giving you any meaningful security. Andy's
> example gives a scenario where by constraining your *userland* sufficiently
> you can get close to having the same guarantees, but that involves you
> having a read-only filesystem and takes you even further away from having a
> general purpose computer.
>
> If you don't want Secure Boot, turn it off. If you want Secure Boot, use a
> kernel that behaves in a way that actually increases your security.
That assumes you *can* turn that shit off. On the hardware where manufacturer
has installed firmware that doesn't allow that SB is a misfeature that has
to be worked around. Making that harder might improve the value of SB to
said manufacturers, but what's the benefit for everybody else?
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-03 21:26 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes,
linux-man, jlee, LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CACdnJuvheCbuvTLyDWMQWcUytc4EvuSUaEKywfEX8Kp6qYL9dg@mail.gmail.com>
On Tue, Apr 3, 2018 at 2:08 PM, Matthew Garrett <mjg59@google.com> wrote:
>
> Secure Boot ensures that the firmware will only load signed bootloaders. If
> a signed bootloader loads a kernel that's effectively an unsigned
> bootloader, there's no point in using Secure Boot
Bullshit.
I may want to know that I'm running *my* kernel, but once that is the
case, I trust it.
In fact, I tend to trust it more than some random vendor key. You should too.
Your whole argument is FUNDAMENTALLY garbage. It's the Disney kind of
garbage. It was garbage back then, and it's garbage now.
It is also garbage for a simple technical reason: secure boot can be
hard to turn off. Sometimes "turn off" means "you just have to add
your own keys".
Yes, on x86 hardware at least at some point MS actually had the rule
that it has to be something you can turn off. That rule is apparently
not true on ARM, though.
Seriously. You sound like you're parroting some party line, not like
you are answering the actual question.
So again: why do you conflate the two issues?
If you want lockdown, fine, enable it. But what the F*CK does that
have to do with whether you had secure boot or not?
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-03 21:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFy4ZVaar3sf7bSVYtU5sRkv18x9W8HMEwF9O9beQK4wbw@mail.gmail.com>
On Tue, Apr 3, 2018 at 2:26 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> On Tue, Apr 3, 2018 at 2:08 PM, Matthew Garrett <mjg59@google.com> wrote:
> >
> > Secure Boot ensures that the firmware will only load signed
bootloaders. If
> > a signed bootloader loads a kernel that's effectively an unsigned
> > bootloader, there's no point in using Secure Boot
> Bullshit.
> I may want to know that I'm running *my* kernel, but once that is the
> case, I trust it.
If you don't believe that your self-signed kernel is going to be a threat
against your security model then great! Don't turn this on when you build
it. But if you built a kernel that didn't have this lockdown functionality
and got it signed with, say, Red Hat's signing keys, anyone could take Red
Hat's bootloader chain and that kernel and subvert the Secure Boot chain on
any machine that trusts the third party signing key (ie, basically all of
them)
> Yes, on x86 hardware at least at some point MS actually had the rule
> that it has to be something you can turn off. That rule is apparently
> not true on ARM, though.
Correct - there's no requirement that it be something you can disable on
ARM, but since Microsoft won't sign any third-party code for ARM anyway it
makes no difference to this discussion.
> If you want lockdown, fine, enable it. But what the F*CK does that
> have to do with whether you had secure boot or not?
Because a kernel signed with a generally trusted key that doesn't implement
any lockdown functionality is effectively a bootloader that will load
unsigned material on most machines on the market, which reduces the
security of users running those machines with Secure Boot enabled.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-03 21:37 UTC (permalink / raw)
To: Alexander Viro
Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes,
linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <20180403212102.GL30522@ZenIV.linux.org.uk>
On Tue, Apr 3, 2018 at 2:21 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Tue, Apr 03, 2018 at 09:08:54PM +0000, Matthew Garrett wrote:
> > If you don't want Secure Boot, turn it off. If you want Secure Boot,
use a
> > kernel that behaves in a way that actually increases your security.
> That assumes you *can* turn that shit off. On the hardware where
manufacturer
> has installed firmware that doesn't allow that SB is a misfeature that has
> to be worked around. Making that harder might improve the value of SB to
> said manufacturers, but what's the benefit for everybody else?
This is why Shim has support for its own key database, as well as allowing
you to disable further signature validation. If the hardware supports third
party code at all, you can just use Shim to sidestep any unreasonable
restrictions the vendor has imposed.
(This doesn't help with systems that don't support third party code at all,
but this patchset does nothing to make that worse - that hardware wouldn't
boot your own kernel before this patchset, and it won't afterwards either)
^ permalink raw reply
* Re: [RESEND PATCH V4] pidns: introduce syscall translate_pid
From: Andrew Morton @ 2018-04-03 21:38 UTC (permalink / raw)
To: nagarathnam.muthusamy
Cc: linux-api, linux-kernel, ebiederm, khlebnikov, serge.hallyn, oleg,
luto, jannh, prakash.sangappa
In-Reply-To: <1522706249-11578-1-git-send-email-nagarathnam.muthusamy@oracle.com>
On Mon, 2 Apr 2018 15:57:29 -0600 nagarathnam.muthusamy@oracle.com wrote:
> pid_t translate_pid(pid_t pid, int source, int target);
>
> This syscall converts pid from source pid-ns into pid in target pid-ns.
> If pid is unreachable from target pid-ns it returns zero.
>
> Pid-namespaces are referred file descriptors opened to proc files
> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
> refers to current pid namespace, same as file /proc/self/ns/pid.
>
> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
> translation requires scanning all tasks. Also pids could be translated
> by sending them through unix socket between namespaces, this method is
> slow and insecure because other side is exposed inside pid namespace.
>
> Examples:
> translate_pid(pid, ns, -1) - get pid in our pid namespace
> translate_pid(pid, -1, ns) - get pid in other pid namespace
> translate_pid(1, ns, -1) - get pid of init task for namespace
> translate_pid(pid, -1, ns) > 0 - is pid is reachable from ns?
> translate_pid(1, ns1, ns2) > 0 - is ns1 inside ns2?
> translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
> translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?
>
> Error codes:
> EBADF - file descriptor is closed
> EINVAL - file descriptor isn't pid-namespace
> ESRCH - task not found in @source namespace
Presumably a manpage is planned?
This changelog doesn't explain what the value is to our users. I
assume it is a performance optimization because "backward translation
requires scanning all tasks"? If so, please show us real-world
examples of the performance benefit from this patch, and please go to
great lengths to explain to us why this optimisation is needed by our
users.
^ permalink raw reply
* Re: [RESEND PATCH V4] pidns: introduce syscall translate_pid
From: Nagarathnam Muthusamy @ 2018-04-03 21:45 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-api, linux-kernel, ebiederm, khlebnikov, serge.hallyn, oleg,
luto, jannh, prakash.sangappa
In-Reply-To: <20180403143838.614ecc083835d07d409a699c@linux-foundation.org>
On 04/03/2018 02:38 PM, Andrew Morton wrote:
> On Mon, 2 Apr 2018 15:57:29 -0600 nagarathnam.muthusamy@oracle.com wrote:
>
>> pid_t translate_pid(pid_t pid, int source, int target);
>>
>> This syscall converts pid from source pid-ns into pid in target pid-ns.
>> If pid is unreachable from target pid-ns it returns zero.
>>
>> Pid-namespaces are referred file descriptors opened to proc files
>> /proc/[pid]/ns/pid or /proc/[pid]/ns/pid_for_children. Negative argument
>> refers to current pid namespace, same as file /proc/self/ns/pid.
>>
>> Kernel expose virtual pids in /proc/[pid]/status:NSpid, but backward
>> translation requires scanning all tasks. Also pids could be translated
>> by sending them through unix socket between namespaces, this method is
>> slow and insecure because other side is exposed inside pid namespace.
>>
>> Examples:
>> translate_pid(pid, ns, -1) - get pid in our pid namespace
>> translate_pid(pid, -1, ns) - get pid in other pid namespace
>> translate_pid(1, ns, -1) - get pid of init task for namespace
>> translate_pid(pid, -1, ns) > 0 - is pid is reachable from ns?
>> translate_pid(1, ns1, ns2) > 0 - is ns1 inside ns2?
>> translate_pid(1, ns1, ns2) == 0 - is ns1 outside ns2?
>> translate_pid(1, ns1, ns2) == 1 - is ns1 equal ns2?
>>
>> Error codes:
>> EBADF - file descriptor is closed
>> EINVAL - file descriptor isn't pid-namespace
>> ESRCH - task not found in @source namespace
> Presumably a manpage is planned?
>
> This changelog doesn't explain what the value is to our users. I
> assume it is a performance optimization because "backward translation
> requires scanning all tasks"? If so, please show us real-world
> examples of the performance benefit from this patch, and please go to
> great lengths to explain to us why this optimisation is needed by our
> users.
One of the usecase by Oracle database involves multiple levels of
nested pid namespaces and we require pid translation between the
levels. Discussions on the particular usecase, why any of the existing
methods was not usable happened in the following thread.
https://patchwork.kernel.org/patch/10276785/
At the end, it was agreed that this patch along with flocks will solve the
issue.
Thanks,
Nagarathnam.
^ permalink raw reply
* Re: [RESEND PATCH V4] pidns: introduce syscall translate_pid
From: Nagarathnam Muthusamy @ 2018-04-03 21:51 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-api, linux-kernel, ebiederm, khlebnikov, serge.hallyn, oleg,
luto, jannh, prakash.sangappa
In-Reply-To: <20180403145248.fb4cd8c5ccd270ca77fd18f3@linux-foundation.org>
On 04/03/2018 02:52 PM, Andrew Morton wrote:
> On Tue, 3 Apr 2018 14:45:28 -0700 Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com> wrote:
>
>>> This changelog doesn't explain what the value is to our users. I
>>> assume it is a performance optimization because "backward translation
>>> requires scanning all tasks"? If so, please show us real-world
>>> examples of the performance benefit from this patch, and please go to
>>> great lengths to explain to us why this optimisation is needed by our
>>> users.
>> One of the usecase by Oracle database involves multiple levels of
>> nested pid namespaces and we require pid translation between the
>> levels. Discussions on the particular usecase, why any of the existing
>> methods was not usable happened in the following thread.
>>
>> https://patchwork.kernel.org/patch/10276785/
>>
>> At the end, it was agreed that this patch along with flocks will solve the
>> issue.
> Nobody who reads this patch's changelog will know any of this. Please
> let's get all this information into the proper place.
Sure! Will resend the patch with updated change log.
Thanks,
Nagarathnam.
>
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Andy Lutomirski @ 2018-04-03 21:51 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Linus Torvalds, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CACdnJuutJeeaaB2kwma0MMd9uDDbKavoHEk4koDLe1M6gYZWXQ@mail.gmail.com>
On Tue, Apr 3, 2018 at 12:29 PM, Matthew Garrett <mjg59@google.com> wrote:
> On Tue, Apr 3, 2018 at 9:46 AM Andy Lutomirski <luto@kernel.org> wrote:
>> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote:
>> > A kernel that allows users arbitrary access to ring 0 is just an
>> > overfeatured bootloader. Why would you want secure boot in that case?
>
>> To get a chain of trust. I can provision a system with some public
>> keys, stored in UEFI authenticated variables, such that the system
>> will only boot a signed image. That signed image, can, in turn, load
>> a signed (or hashed or otherwise verfified) kernel and a verified
>> initramfs. The initramfs can run a full system from a verified (using
>> dm-verity or similar) filesystem, for example. Now it's very hard to
>> persistently attack this system. Chromium OS does something very much
>> like this, except that it doesn't use UEFI as far as I know. So does
>> iOS, and so do some Android versions. None of this requires lockdown,
>> or even a separation between usermode and kernelmode, to work
>> correctly. One could even do this on an MMU-less system if one really
>> cared to. More usefully, someone probably has done this using a
>> unikernel.
>
> That's only viable if you're the only person with the ability to sign stuff
> for your machine - the moment there are generic distributions that your
> machine trusts, an attacker can use one as a bootloader to compromise your
> trust chain.
If you removed "as a bootloader", then I agree with that sentence.
Can someone please explain why the UEFI crowd cares so much about "as
a bootloader"? Once I'm able to install an OS (Linux kernel +
bootloader, Windows embedded doodad, OpenBSD, whatever) on your
machine, I can use your peripherals, read your data, write your data,
see your keystrokes, use your network connection, re-flash your BIOS
(at least as well as any OS can), run VMs, and generally own your
system. Somehow you all seem fine with all of this, except that the
fact that I can chainload something else gives UEFI people the
willies.
Can someone explain why?
^ permalink raw reply
* Re: [RESEND PATCH V4] pidns: introduce syscall translate_pid
From: Andrew Morton @ 2018-04-03 21:52 UTC (permalink / raw)
To: Nagarathnam Muthusamy
Cc: linux-api, linux-kernel, ebiederm, khlebnikov, serge.hallyn, oleg,
luto, jannh, prakash.sangappa
In-Reply-To: <678f275b-8d78-9b0f-177f-5ff5c9c55657@oracle.com>
On Tue, 3 Apr 2018 14:45:28 -0700 Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com> wrote:
> > This changelog doesn't explain what the value is to our users. I
> > assume it is a performance optimization because "backward translation
> > requires scanning all tasks"? If so, please show us real-world
> > examples of the performance benefit from this patch, and please go to
> > great lengths to explain to us why this optimisation is needed by our
> > users.
>
> One of the usecase by Oracle database involves multiple levels of
> nested pid namespaces and we require pid translation between the
> levels. Discussions on the particular usecase, why any of the existing
> methods was not usable happened in the following thread.
>
> https://patchwork.kernel.org/patch/10276785/
>
> At the end, it was agreed that this patch along with flocks will solve the
> issue.
Nobody who reads this patch's changelog will know any of this. Please
let's get all this information into the proper place.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Andy Lutomirski @ 2018-04-03 21:58 UTC (permalink / raw)
To: David Howells
Cc: Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris,
Alan Cox, Linus Torvalds, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <13189.1522784944@warthog.procyon.org.uk>
On Tue, Apr 3, 2018 at 12:49 PM, David Howells <dhowells@redhat.com> wrote:
> Andy Lutomirski <luto@kernel.org> wrote:
>
>> >>> A kernel that allows users arbitrary access to ring 0 is just an
>> >>> overfeatured bootloader. Why would you want secure boot in that case?
>> >>
>> >> To get a chain of trust.
>> >
>> > You don't have a chain of trust that you can trust in that case.
>> >
>> Please elaborate on why I can’t trust it.
>
> If the user can arbitrarily modify the running kernel image, you cannot trust
> anything. You cannot determine the trustworthiness of something because your
> basis for determining that trust can be compromised.
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't. About the only think I can come up with is that root generally
has a hard time directly reading kernel keyring data.
But if we really think that kernel keyring data is so sacred, let's
please solve it properly using SGX or some hypervisor doodad like
Microsoft's Credential Guard. Protecting the keyring with lockdown is
a whole lot of annoyance without all that much gain.
>
>> Please also elaborate on how lockdown helps at all.
>
> Stopping the kernel from being arbitrarily modified allows you to preserve
> your trust.
If I build a voting machine, an ATM, or a server that runs Panera
Bread's website, I can certainly issue a press release that says "hey,
the bad guy just downloaded tens of millions of customer records, but
they didn't actually get to run CPL0 code, so all is well."
</sarcasm>
>
> Stopping the kernel from being arbitrarily read stops any encryption keys it
> may be using from being retrieved.
If I build a server that runs Panera Bread 2.0's website, and the
attacker exploits my machine to steal tens of millions of customer
records by getting the machine to talk to some database server using
keys that are securely stored in the kernel keyring, I would feel
sooooooo much better knowing that the attacker didn't also manage to
extract the key that lets the machine talk to the database server.
Never mind that the attacker already stole the entire contents of the
database.
</sarcasm>
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: David Howells @ 2018-04-03 22:32 UTC (permalink / raw)
To: Andy Lutomirski
Cc: dhowells, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox,
Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CALCETrX4CuHVpn38R24TCcJgCBLSbh-sOD-qcD5kYF8Zo53ZJw@mail.gmail.com>
Andy Lutomirski <luto@kernel.org> wrote:
> > If the user can arbitrarily modify the running kernel image, you cannot
> > trust anything. You cannot determine the trustworthiness of something
> > because your basis for determining that trust can be compromised.
>
> 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't.
Eh? If the attacker can't what? Did you mean to put "can" at the end of that
rather than "can't"? I don't see why the kernel-level trust would be
compromised if an attacker can't get root and can't modify the running kernel
image.
Here's a simple scenario: You boot your machine. You have module verification
keys in your kernel. You have /dev/mem available for root to read/write. A
program running as root can modify the keys in your kernel or just disable the
checking code entirely. It can now insmod any module it likes. You may as
well not bother with signed modules. In fact, it can modify the running
kernel image in any way it likes, without even having to load modules.
There's no point bothering with UID/GID checking either.
> > Stopping the kernel from being arbitrarily read stops any encryption keys it
> > may be using from being retrieved.
>
> If I build a server that runs Panera Bread 2.0's website, and the
> attacker exploits my machine to steal tens of millions of customer
> records by getting the machine to talk to some database server using
> keys that are securely stored in the kernel keyring, ...
I was thinking more in terms of preventing access to the encrypted data on
your own disk. The key for that could be unlocked using a TPM, but the
session key then has to be retained in RAM for performance reasons unless you
can transfer the session key to, say, your SATA controller without it going
through the CPU.
However, if /dev/mem can be read, any root process can extract the session key
for your disk.
But, as you suggest, they could also protect secrets used in communications.
However, the communications themselves have to be exposed to userspace for
userspace to be able to use them. That is unavoidable. The kernel keyring,
for example, tries to restrict who can even see a key, much less use it as
much as possible - but ptrace() exists... You are no less vulnerable if the
key is held in a userspace process; then the attacker can get the key and the
data.
If the kernel is locked down, the aim is to try and make sure that keys
stashed in the kernel cannot be read, though they have to be able to be used,
or there's no point to them.
David
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Andy Lutomirski @ 2018-04-03 22:39 UTC (permalink / raw)
To: David Howells
Cc: Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris,
Alan Cox, Linus Torvalds, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <9349.1522794769@warthog.procyon.org.uk>
On Tue, Apr 3, 2018 at 3:32 PM, David Howells <dhowells@redhat.com> wrote:
> Andy Lutomirski <luto@kernel.org> wrote:
>
>> > If the user can arbitrarily modify the running kernel image, you cannot
>> > trust anything. You cannot determine the trustworthiness of something
>> > because your basis for determining that trust can be compromised.
>>
>> 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't.
>
> Eh? If the attacker can't what? Did you mean to put "can" at the end of that
> rather than "can't"? I don't see why the kernel-level trust would be
> compromised if an attacker can't get root and can't modify the running kernel
> image.
Whoops, yes.
>
> Here's a simple scenario: You boot your machine. You have module verification
> keys in your kernel. You have /dev/mem available for root to read/write. A
> program running as root can modify the keys in your kernel or just disable the
> checking code entirely. It can now insmod any module it likes. You may as
> well not bother with signed modules. In fact, it can modify the running
> kernel image in any way it likes, without even having to load modules.
I don't particularly disagree with any of this, but you seem to be
saying "if you've bought into the party line wrt signed modules, you
had better enable lockdown, too". I *don't* buy into the party line
about why signed modules should be needed for Secure Boot.
> 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.
>
>> > Stopping the kernel from being arbitrarily read stops any encryption keys it
>> > may be using from being retrieved.
>>
>> If I build a server that runs Panera Bread 2.0's website, and the
>> attacker exploits my machine to steal tens of millions of customer
>> records by getting the machine to talk to some database server using
>> keys that are securely stored in the kernel keyring, ...
>
> I was thinking more in terms of preventing access to the encrypted data on
> your own disk. The key for that could be unlocked using a TPM, but the
> session key then has to be retained in RAM for performance reasons unless you
> can transfer the session key to, say, your SATA controller without it going
> through the CPU.
>
> 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.
>
> But, as you suggest, they could also protect secrets used in communications.
> However, the communications themselves have to be exposed to userspace for
> userspace to be able to use them. That is unavoidable. The kernel keyring,
> for example, tries to restrict who can even see a key, much less use it as
> much as possible - but ptrace() exists... You are no less vulnerable if the
> key is held in a userspace process; then the attacker can get the key and the
> data.
>
> If the kernel is locked down, the aim is to try and make sure that keys
> stashed in the kernel cannot be read, though they have to be able to be used,
> or there's no point to them.
Sure. I have no problem with having an upstream kernel have a
lockdown feature, although I think that feature should distinguish
between reads and writes. 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.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-03 22:46 UTC (permalink / raw)
To: Andy Lutomirski
Cc: David Howells, Matthew Garrett, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CALCETrV6E+r942K+fu-ALNf-x6qOZ3o1hNKGeu7qEMvr8sMP9A@mail.gmail.com>
On Tue, Apr 3, 2018 at 3:39 PM, Andy Lutomirski <luto@kernel.org> wrote:
>
> Sure. I have no problem with having an upstream kernel have a
> lockdown feature, although I think that feature should distinguish
> between reads and writes. 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.
So this is where I violently agree with Andy.
For example, I love signed kernel modules. The fact that I love them
has absolutely zero to do with secure boot, though. There is
absolutely no linkage between the two issues: I use (self-)signed
kernel modules simply because I think it's a good thing in general.
The same thing is true of some lockdown patch. Maybe it's a good thing
in general. But whether it's a good thing is _entirely_ independent of
any secure boot issue. I can see using secure boot without it, but I
can very much also see using lockdown without secure boot.
The two things are simply entirely orthogonal. They have _zero_
overlap. I'm not seeing why they'd be linked at all in any way.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-03 22:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFxKzxdRZthzaokaGPAsWCp3a-p3aVfJSutF+9Fp9sbaVA@mail.gmail.com>
On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> For example, I love signed kernel modules. The fact that I love them
> has absolutely zero to do with secure boot, though. There is
> absolutely no linkage between the two issues: I use (self-)signed
> kernel modules simply because I think it's a good thing in general.
> The same thing is true of some lockdown patch. Maybe it's a good thing
> in general. But whether it's a good thing is _entirely_ independent of
> any secure boot issue. I can see using secure boot without it, but I
> can very much also see using lockdown without secure boot.
> The two things are simply entirely orthogonal. They have _zero_
> overlap. I'm not seeing why they'd be linked at all in any way.
Lockdown is clearly useful without Secure Boot (and I intend to deploy it
that way for various things), but I still don't understand why you feel
that the common case of booting a kernel from a boot chain that's widely
trusted derives no benefit from it being harder to subvert that kernel into
subverting that boot chain. For cases where you're self-signing and feel
happy about that, you just set CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to n and
everyone's happy?
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Andy Lutomirski @ 2018-04-03 22:53 UTC (permalink / raw)
To: Matthew Garrett
Cc: Linus Torvalds, Andrew Lutomirski, David Howells, Ard Biesheuvel,
James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CACdnJusSfwULV-ubvgtYd8G_cTF4LnJ4DAeTCux4XRhHKVpBUw@mail.gmail.com>
On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett <mjg59@google.com> wrote:
> On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds
> <torvalds@linux-foundation.org>
> wrote:
>
>> For example, I love signed kernel modules. The fact that I love them
>> has absolutely zero to do with secure boot, though. There is
>> absolutely no linkage between the two issues: I use (self-)signed
>> kernel modules simply because I think it's a good thing in general.
>
>> The same thing is true of some lockdown patch. Maybe it's a good thing
>> in general. But whether it's a good thing is _entirely_ independent of
>> any secure boot issue. I can see using secure boot without it, but I
>> can very much also see using lockdown without secure boot.
>
>> The two things are simply entirely orthogonal. They have _zero_
>> overlap. I'm not seeing why they'd be linked at all in any way.
>
> Lockdown is clearly useful without Secure Boot (and I intend to deploy it
> that way for various things), but I still don't understand why you feel
> that the common case of booting a kernel from a boot chain that's widely
> trusted derives no benefit from it being harder to subvert that kernel into
> subverting that boot chain. For cases where you're self-signing and feel
> happy about that, you just set CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to n and
> everyone's happy?
I would like to see distros that want Secure Boot to annoy users by
enabling Lockdown be honest about the fact that it's an annoyance and
adds very little value by having to carry a patch that was rejected by
the upstream kernel.
-Andy
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-03 23:08 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CACdnJusSfwULV-ubvgtYd8G_cTF4LnJ4DAeTCux4XRhHKVpBUw@mail.gmail.com>
On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett <mjg59@google.com> wrote:
>
> Lockdown is clearly useful without Secure Boot (and I intend to deploy it
> that way for various things), but I still don't understand why you feel
> that the common case of booting a kernel from a boot chain that's widely
> trusted derives no benefit from it being harder to subvert that kernel into
> subverting that boot chain.
It has NOTHING TO DO WITH "HARDER TO SUBVERT".
THE TWO FEATURES HAVE NOTHING TO DO WITH EACH OTHER WHAT-SO-EVER.
I do not want my kernel to act differently depending on some really
esoteric detail in how it was booted. That is fundamentally wrong.
Is that really so hard to understand?
Look at it this way: maybe lockdown breaks some application because
that app does something odd. I get a report of that happening, and it
so happens that the reporter is running the same distro I am, so I try
it with his exact kernel configuration, and it works for me.
It is *entirely* non-obvious that the reporter happened to run a
distro kernel that had secure boot enabled, and I obviously do not.
See what the problem is? Tying these things magically together IS A BAD IDEA.
And when people ask you why you did it, YOU HAVE YET TO COME UP WITH A
SINGLE ACTUAL RESPONSE.
Instead, you just ask people why they care, or tell people to not enable it.
Seriously, Matthew, it's WRONG to tie things together in magic ways
when they have nothing what-so-ever to do with each other.
So no. The answer is simply "don't tie the two things together".
And dammit, if you tie them together, you had damn well have a good
reason. So far, your reasons have _literally_ been "Why not?" and
tried to make the onus be on others to explain to you why not.
That's not the right approach to begin with, Matthew. The onus is on
*you* to explain why you tied them together, not on others to explain
to you - over and over - that they have nothing to do with each other.
This discussion is over until you give an actual honest-to-goodness
reason for why you tied the two features together. No more "Why not?"
crap.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-03 23:09 UTC (permalink / raw)
To: luto
Cc: Linus Torvalds, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CALCETrXC-mL07YvGrvqaUQrbv+3fv2G9rGuQoMohaxG=QUQn2g@mail.gmail.com>
On Tue, Apr 3, 2018 at 3:53 PM Andy Lutomirski <luto@kernel.org> wrote:
> On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett <mjg59@google.com> wrote:
> > Lockdown is clearly useful without Secure Boot (and I intend to deploy
it
> > that way for various things), but I still don't understand why you feel
> > that the common case of booting a kernel from a boot chain that's widely
> > trusted derives no benefit from it being harder to subvert that kernel
into
> > subverting that boot chain. For cases where you're self-signing and feel
> > happy about that, you just set CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to n
and
> > everyone's happy?
> I would like to see distros that want Secure Boot to annoy users by
> enabling Lockdown be honest about the fact that it's an annoyance and
> adds very little value by having to carry a patch that was rejected by
> the upstream kernel.
I disagree with the assertion that it adds very little value, but if you
want to reject a technically useful patch for political reasons then I'm
well beyond the point of caring.
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-03 23:10 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CA+55aFzG==xr2OLK8F03RH0nkUDeP6btWqepFTuHZqkPTAOWjQ@mail.gmail.com>
On Tue, Apr 3, 2018 at 4:08 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> This discussion is over until you give an actual honest-to-goodness
> reason for why you tied the two features together. No more "Why not?"
> crap.
Side note: I suspect the reason is something along the lines of "there
are political reasons".
But dammit, if that's the case, those should be documented and
explained, not answered with "why not" when people ask why something
is the case.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: David Howells @ 2018-04-03 23:12 UTC (permalink / raw)
To: Andy Lutomirski
Cc: dhowells, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox,
Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
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
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Matthew Garrett @ 2018-04-03 23:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox,
Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man,
jlee, LSM List, linux-api, Kees Cook, linux-efi
In-Reply-To: <CA+55aFzG==xr2OLK8F03RH0nkUDeP6btWqepFTuHZqkPTAOWjQ@mail.gmail.com>
On Tue, Apr 3, 2018 at 4:08 PM Linus Torvalds
<torvalds@linux-foundation.org>
wrote:
> That's not the right approach to begin with, Matthew. The onus is on
> *you* to explain why you tied them together, not on others to explain
> to you - over and over - that they have nothing to do with each other.
1) Secure Boot is intended to permit the construction of a boot chain that
only runs ring 0 code that the user considers trustworthy
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
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
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)
Alternative approaches to achieve (1) rely on severely constraining
userland - ChromeOS, for instance, doesn't impose these restrictions at
present but also doesn't allow users to run arbitrary applications (you're
stuck inside either the Chrome or Android sandbox). So, if the goal is to
achieve (1) when the platform is in this state, what's a more reasonable
alternative?
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-03 23:26 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <CACdnJuv_=ihPut=5OvCYEphdBOn7+JrKacBbNa0n3wv_JvFMzg@mail.gmail.com>
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.
> 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 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.
> 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.
Yet they are a HELL OF A LOT MORE IMPORTANT than this new patch series.
> 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.
I'm done with you. You're not listening, and you're repeating bogus
arguments that make no sense.
No way in hell will I merge anything like this.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: Linus Torvalds @ 2018-04-03 23:27 UTC (permalink / raw)
To: David Howells
Cc: Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris,
Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List,
Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook,
linux-efi
In-Reply-To: <10232.1522797179@warthog.procyon.org.uk>
On Tue, Apr 3, 2018 at 4:12 PM, David Howells <dhowells@redhat.com> wrote:
>
> What use is secure boot if processes run as root can subvert your kernel?
Stop this idiocy.
The above has now been answered multiple times, several different ways.
The "point" of secure boot may be that you had no choice, or there was
no point at all, it just came that way.
Or the "point" of secure boot may be that you don't trust anybody else
than yourself, but once you've booted you do trust what you booted.
But the *real* point is that this has nothing what-so-ever to do with
secure boot. You may want (or not want) lockdown independently of it.
Don't tie magic boot issues with kernel runtime behavior.
Linus
^ permalink raw reply
* Re: [GIT PULL] Kernel lockdown for secure boot
From: David Howells @ 2018-04-03 23:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: dhowells, Andy Lutomirski, Matthew Garrett, Ard Biesheuvel,
James Morris, Alan Cox, Greg Kroah-Hartman,
Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli,
LSM List, Linux API, Kees Cook, linux-efi
In-Reply-To: <CA+55aFxKzxdRZthzaokaGPAsWCp3a-p3aVfJSutF+9Fp9sbaVA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> The same thing is true of some lockdown patch. Maybe it's a good thing
> in general. But whether it's a good thing is _entirely_ independent of
> any secure boot issue. I can see using secure boot without it, but I
> can very much also see using lockdown without secure boot.
>
> The two things are simply entirely orthogonal. They have _zero_
> overlap. I'm not seeing why they'd be linked at all in any way.
I'm not sure I agree. Here's my reasoning:
(1) Lockdown mode really needs to activated during kernel boot, before
userspace has a chance to run, otherwise there's a window of opportunity
in which the kernel *isn't* locked down.
(2) If the kernel isn't booted in secure boot mode, then there's the
opportunity to tamper before the kernel even starts booting.
(3) There doesn't seem any point in booting in secure boot mode if you don't
protect the running kernel image against tampering. What does it mean to
be in "secure boot mode" in that case? If the kernel can be tampered
with, it would seem to be, by definition, insecure.
(4) You can't validly promise the next OS you kexec that *it* is started in
secure boot mode if you don't stop your image from being tampered with.
Note that this doesn't prevent a compromised kernel from lying to the
next OS.
(5) Tampering with a running kernel can be achieved in a variety of ways:
loading of arbitrary modules, loading of modified firmware, direct access
to devices that can effect DMA, writing to /dev/mem, ...
(6) We need to be able to load modules and firmware, but these can be signed,
hashed or measured so we have some idea of their provenance - but signing
can be worked around if, say, /dev/mem is writable.
(7) If you told the BIOS[*] that you want to be in secure boot mode, then the
kernel should honour that and try to prevent tampering with the image.
(8) Turning lockdown mode on if the kernel is booted in secure boot seems to
be the way to achieve this.
(9) BIOS vendors can blacklist any of the components - say the SHIM - to
prevent an insecure kernel from being used to compromise and kexec
another OS.
Note that I've provided a kernel command line parameter that will turn
lockdown mode on arbitrarily - but that can be turned off by editing the
parameters in grub.cfg, say.
David
[*] Yeah, I know, this is an x86-centric view.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox