diff mbox series

[22/27] Lock down kprobes

Message ID 20190325220954.29054-23-matthewgarrett@google.com (mailing list archive)
State New, archived
Headers show
Series [PULL,REQUEST] Lockdown patches for 5.2 | expand

Commit Message

Matthew Garrett March 25, 2019, 10:09 p.m. UTC
From: David Howells <dhowells@redhat.com>

Disallow the creation of kprobes when the kernel is locked down by
preventing their registration.  This prevents kprobes from being used to
access kernel memory, either to make modifications or to steal crypto data.

Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Cc: davem@davemloft.net
Cc: Masami Hiramatsu <mhiramat@kernel.org>
---
 kernel/kprobes.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Masami Hiramatsu (Google) March 26, 2019, 12:29 p.m. UTC | #1
On Mon, 25 Mar 2019 15:09:49 -0700
Matthew Garrett <matthewgarrett@google.com> wrote:

> From: David Howells <dhowells@redhat.com>
> 
> Disallow the creation of kprobes when the kernel is locked down by
> preventing their registration.  This prevents kprobes from being used to
> access kernel memory, either to make modifications or to steal crypto data.

Hmm, if you enforce signature check of modules, those modules
should be allowed to use kprobes?
I think we should introduce some kind of trust inheritance from
signed (trusted) modules.

Thank you,

> 
> Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
> Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
> Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
> Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
> Cc: davem@davemloft.net
> Cc: Masami Hiramatsu <mhiramat@kernel.org>
> ---
>  kernel/kprobes.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index f4ddfdd2d07e..6f66cca8e2c6 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -1552,6 +1552,9 @@ int register_kprobe(struct kprobe *p)
>  	struct module *probed_mod;
>  	kprobe_opcode_t *addr;
>  
> +	if (kernel_is_locked_down("Use of kprobes"))
> +		return -EPERM;
> +
>  	/* Adjust probe address from symbol */
>  	addr = kprobe_addr(p);
>  	if (IS_ERR(addr))
> -- 
> 2.21.0.392.gf8f6787159e-goog
>
Matthew Garrett March 26, 2019, 5:41 p.m. UTC | #2
On Tue, Mar 26, 2019 at 5:30 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> On Mon, 25 Mar 2019 15:09:49 -0700
> Matthew Garrett <matthewgarrett@google.com> wrote:
>
> > From: David Howells <dhowells@redhat.com>
> >
> > Disallow the creation of kprobes when the kernel is locked down by
> > preventing their registration.  This prevents kprobes from being used to
> > access kernel memory, either to make modifications or to steal crypto data.
>
> Hmm, if you enforce signature check of modules, those modules
> should be allowed to use kprobes?
> I think we should introduce some kind of trust inheritance from
> signed (trusted) modules.

Is there any way to install a kprobe /without/ it coming from a
module? The presumption in lockdown mode is that module signing is
enforced, so I'll admit to not being entirely clear on why this patch
is needed in that case.
Masami Hiramatsu (Google) March 26, 2019, 10:47 p.m. UTC | #3
On Tue, 26 Mar 2019 10:41:23 -0700
Matthew Garrett <mjg59@google.com> wrote:

> On Tue, Mar 26, 2019 at 5:30 AM Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > On Mon, 25 Mar 2019 15:09:49 -0700
> > Matthew Garrett <matthewgarrett@google.com> wrote:
> >
> > > From: David Howells <dhowells@redhat.com>
> > >
> > > Disallow the creation of kprobes when the kernel is locked down by
> > > preventing their registration.  This prevents kprobes from being used to
> > > access kernel memory, either to make modifications or to steal crypto data.
> >
> > Hmm, if you enforce signature check of modules, those modules
> > should be allowed to use kprobes?
> > I think we should introduce some kind of trust inheritance from
> > signed (trusted) modules.
> 
> Is there any way to install a kprobe /without/ it coming from a
> module? The presumption in lockdown mode is that module signing is
> enforced, so I'll admit to not being entirely clear on why this patch
> is needed in that case.

Yes, there are 2 paths, ftrace and perf(bpf). If you want to disable ftrace
path (which start from user's input via tracefs), this should be done in
trace_kprobe_create()@kernel/trace/trace_kprobe.c.
If you want to disable both, __register_trace_kprobe()@kernel/trace/trace_kprobe.c
is the best place.

Thank you,
diff mbox series

Patch

diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index f4ddfdd2d07e..6f66cca8e2c6 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1552,6 +1552,9 @@  int register_kprobe(struct kprobe *p)
 	struct module *probed_mod;
 	kprobe_opcode_t *addr;
 
+	if (kernel_is_locked_down("Use of kprobes"))
+		return -EPERM;
+
 	/* Adjust probe address from symbol */
 	addr = kprobe_addr(p);
 	if (IS_ERR(addr))