Message ID | 20190326182742.16950-8-matthewgarrett@google.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Add support for kernel lockdown | expand |
On 03/26/19 at 11:27am, 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> > 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 | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > index 67f3a866eabe..a1cc37c8b43b 100644 > --- a/kernel/kexec_file.c > +++ b/kernel/kexec_file.c > @@ -239,6 +239,12 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, > } > > ret = 0; > + > + if (kernel_is_locked_down(reason, LOCKDOWN_INTEGRITY)) { > + ret = -EPERM; > + goto out; > + } > + Checking here is late, it would be good to move the check to earlier code around below code: /* We only trust the superuser with rebooting the system. */ if (!capable(CAP_SYS_BOOT) || kexec_load_disabled) return -EPERM; > break; > > /* All other errors are fatal, including nomem, unparseable > -- > 2.21.0.392.gf8f6787159e-goog > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec Thanks Dave
On Thu, Jun 20, 2019 at 11:43 PM Dave Young <dyoung@redhat.com> wrote: > > On 03/26/19 at 11:27am, 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> > > 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 | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > > index 67f3a866eabe..a1cc37c8b43b 100644 > > --- a/kernel/kexec_file.c > > +++ b/kernel/kexec_file.c > > @@ -239,6 +239,12 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, > > } > > > > ret = 0; > > + > > + if (kernel_is_locked_down(reason, LOCKDOWN_INTEGRITY)) { > > + ret = -EPERM; > > + goto out; > > + } > > + > > Checking here is late, it would be good to move the check to earlier > code around below code: > /* We only trust the superuser with rebooting the system. */ > if (!capable(CAP_SYS_BOOT) || kexec_load_disabled) > return -EPERM; I don't think so - we want it to be possible to load images if they have a valid signature.
On 06/21/19 at 01:18pm, Matthew Garrett wrote: > On Thu, Jun 20, 2019 at 11:43 PM Dave Young <dyoung@redhat.com> wrote: > > > > On 03/26/19 at 11:27am, 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> > > > 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 | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > > > index 67f3a866eabe..a1cc37c8b43b 100644 > > > --- a/kernel/kexec_file.c > > > +++ b/kernel/kexec_file.c > > > @@ -239,6 +239,12 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, > > > } > > > > > > ret = 0; > > > + > > > + if (kernel_is_locked_down(reason, LOCKDOWN_INTEGRITY)) { > > > + ret = -EPERM; > > > + goto out; > > > + } > > > + > > > > Checking here is late, it would be good to move the check to earlier > > code around below code: > > /* We only trust the superuser with rebooting the system. */ > > if (!capable(CAP_SYS_BOOT) || kexec_load_disabled) > > return -EPERM; > > I don't think so - we want it to be possible to load images if they > have a valid signature. I know it works like this way because of the previous patch. But from the patch log "When KEXEC_SIG is not enabled, kernel should not load images", it is simple to check it early for !IS_ENABLED(CONFIG_KEXEC_SIG) && kernel_is_locked_down(reason, LOCKDOWN_INTEGRITY) instead of depending on the late code to verify signature. In that way, easier to understand the logic, no? Thanks Dave
On Sun, Jun 23, 2019 at 6:52 PM Dave Young <dyoung@redhat.com> wrote: > > On 06/21/19 at 01:18pm, Matthew Garrett wrote: > > I don't think so - we want it to be possible to load images if they > > have a valid signature. > > I know it works like this way because of the previous patch. But from > the patch log "When KEXEC_SIG is not enabled, kernel should not load > images", it is simple to check it early for !IS_ENABLED(CONFIG_KEXEC_SIG) && > kernel_is_locked_down(reason, LOCKDOWN_INTEGRITY) instead of depending > on the late code to verify signature. In that way, easier to > understand the logic, no? But that combination doesn't enforce signature validation? We can't depend on !IS_ENABLED(CONFIG_KEXEC_SIG_FORCE) because then it'll enforce signature validation even if lockdown is disabled.
Hi Matthew, On Mon, 2019-06-24 at 14:06 -0700, Matthew Garrett wrote: > On Sun, Jun 23, 2019 at 6:52 PM Dave Young <dyoung@redhat.com> wrote: > > > > On 06/21/19 at 01:18pm, Matthew Garrett wrote: > > > I don't think so - we want it to be possible to load images if they > > > have a valid signature. > > > > I know it works like this way because of the previous patch. But from > > the patch log "When KEXEC_SIG is not enabled, kernel should not load > > images", it is simple to check it early for !IS_ENABLED(CONFIG_KEXEC_SIG) && > > kernel_is_locked_down(reason, LOCKDOWN_INTEGRITY) instead of depending > > on the late code to verify signature. In that way, easier to > > understand the logic, no? > > But that combination doesn't enforce signature validation? We can't > depend on !IS_ENABLED(CONFIG_KEXEC_SIG_FORCE) because then it'll > enforce signature validation even if lockdown is disabled. I agree with Dave. There should be a stub lockdown function to prevent enforcing lockdown when it isn't enabled. Mimi
On Mon, Jun 24, 2019 at 2:27 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > I agree with Dave. There should be a stub lockdown function to > prevent enforcing lockdown when it isn't enabled. Sorry, when what isn't enabled? If no LSMs are enforcing lockdown then the check will return 0. The goal here is for distributions to be able to ship a kernel that has CONFIG_KEXEC_SIG=y, CONFIG_KEXEC_SIG_FORCE=n and at runtime be able to enforce a policy that requires signatures on kexec payloads.
On Mon, 2019-06-24 at 17:02 -0700, Matthew Garrett wrote: > On Mon, Jun 24, 2019 at 2:27 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > I agree with Dave. There should be a stub lockdown function to > > prevent enforcing lockdown when it isn't enabled. > > Sorry, when what isn't enabled? If no LSMs are enforcing lockdown then > the check will return 0. The goal here is for distributions to be able > to ship a kernel that has CONFIG_KEXEC_SIG=y, CONFIG_KEXEC_SIG_FORCE=n > and at runtime be able to enforce a policy that requires signatures on > kexec payloads. Never mind, the call can't be moved earlier.
On 06/24/19 at 02:06pm, Matthew Garrett wrote: > On Sun, Jun 23, 2019 at 6:52 PM Dave Young <dyoung@redhat.com> wrote: > > > > On 06/21/19 at 01:18pm, Matthew Garrett wrote: > > > I don't think so - we want it to be possible to load images if they > > > have a valid signature. > > > > I know it works like this way because of the previous patch. But from > > the patch log "When KEXEC_SIG is not enabled, kernel should not load > > images", it is simple to check it early for !IS_ENABLED(CONFIG_KEXEC_SIG) && > > kernel_is_locked_down(reason, LOCKDOWN_INTEGRITY) instead of depending > > on the late code to verify signature. In that way, easier to > > understand the logic, no? > > But that combination doesn't enforce signature validation? We can't > depend on !IS_ENABLED(CONFIG_KEXEC_SIG_FORCE) because then it'll > enforce signature validation even if lockdown is disabled. Ok, got your point. still something could be improved though, in the switch chunk, the errno, reason and IS_ENABLED(CONFIG_KEXEC_SIG_FORCE) etc is not necessary for this -EPERM case. /* add some comment to describe the behavior */ if (ret && security_is_locked_down(LOCKDOWN_KEXEC)) { ret = -EPERM; goto out; } Thanks Dave
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 67f3a866eabe..a1cc37c8b43b 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -239,6 +239,12 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, } ret = 0; + + if (kernel_is_locked_down(reason, LOCKDOWN_INTEGRITY)) { + ret = -EPERM; + goto out; + } + break; /* All other errors are fatal, including nomem, unparseable