| Message ID | 20190622000358.19895-10-matthewgarrett@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Lockdown as an LSM | expand |
On Fri, Jun 21, 2019 at 05:03:38PM -0700, Matthew Garrett wrote: > From: Jiri Bohac <jbohac@suse.cz> > > When KEXEC_SIG is not enabled, kernel should not load images through > kexec_file systemcall if the kernel is locked down. > > [Modified by David Howells to fit with modifications to the previous patch > and to return -EPERM if the kernel is locked down for consistency with > other lockdowns. Modified by Matthew Garrett to remove the IMA > integration, which will be replaced by integrating with the IMA > architecture policy patches.] > > Signed-off-by: Jiri Bohac <jbohac@suse.cz> Reviewed-by: Kees Cook <keescook@chromium.org> -Kees > Signed-off-by: David Howells <dhowells@redhat.com> > Signed-off-by: Matthew Garrett <mjg59@google.com> > Reviewed-by: Jiri Bohac <jbohac@suse.cz> > cc: kexec@lists.infradead.org > --- > kernel/kexec_file.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > index eec7e5bb2a08..27adb4312b03 100644 > --- a/kernel/kexec_file.c > +++ b/kernel/kexec_file.c > @@ -237,7 +237,10 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, > goto out; > } > > - ret = 0; > + ret = security_locked_down(LOCKDOWN_KEXEC); > + if (ret) > + goto out; > + > break; > > /* All other errors are fatal, including nomem, unparseable > -- > 2.22.0.410.gd8fdbe21b5-goog >
On Fri, 21 Jun 2019, Matthew Garrett wrote: > From: Jiri Bohac <jbohac@suse.cz> > > When KEXEC_SIG is not enabled, kernel should not load images through > kexec_file systemcall if the kernel is locked down. This is not a criticism of the patch but a related issue which I haven't seen discussed (apologies if it has). If signed code is loaded into ring 0, verified by the kernel, then executed, you still lose your secure/trusted/verified boot state. If the currently running kernel has been runtime-compromised, any signature verification performed by the kernel cannot be trusted. This problem is out of scope for the lockdown threat model (which naturally cannot include a compromised kernel), but folk should be aware that signature-verified kexec does not provide equivalent assurance to a full reboot on a secure-boot system. Potential mitigations here include runtime integrity verification of the kernel via a separate security monitor (hypervisor, SMM, TEE etc.) or some kind of platform support for kexec verification.
On Wed, Jun 26, 2019 at 9:59 PM James Morris <jmorris@namei.org> wrote: > This is not a criticism of the patch but a related issue which I haven't > seen discussed (apologies if it has). > > If signed code is loaded into ring 0, verified by the kernel, then > executed, you still lose your secure/trusted/verified boot state. If the > currently running kernel has been runtime-compromised, any signature > verification performed by the kernel cannot be trusted. > > This problem is out of scope for the lockdown threat model (which > naturally cannot include a compromised kernel), but folk should be aware > that signature-verified kexec does not provide equivalent assurance to a > full reboot on a secure-boot system. By that metric, on a secure boot system how do we determine that code running in the firmware environment wasn't compromised before it launched the initial signed kernel?
On Thu, 27 Jun 2019, Matthew Garrett wrote: > By that metric, on a secure boot system how do we determine that code > running in the firmware environment wasn't compromised before it > launched the initial signed kernel? Remote attestation tied to a hardware root of trust, before allowing access to any further resources.
On Thu, Jun 27, 2019 at 11:14 AM James Morris <jmorris@namei.org> wrote: > > On Thu, 27 Jun 2019, Matthew Garrett wrote: > > > By that metric, on a secure boot system how do we determine that code > > running in the firmware environment wasn't compromised before it > > launched the initial signed kernel? > > Remote attestation tied to a hardware root of trust, before allowing > access to any further resources. If you use IMA you can get the same guarantees over kexec.
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index eec7e5bb2a08..27adb4312b03 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -237,7 +237,10 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, goto out; } - ret = 0; + ret = security_locked_down(LOCKDOWN_KEXEC); + if (ret) + goto out; + break; /* All other errors are fatal, including nomem, unparseable