[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACdnJuss=NmcxS0UoTeopYzipt53ba5GTBwQ+YtJQXLj7_Q10w@mail.gmail.com>
Date: Tue, 26 Mar 2019 10:41:23 -0700
From: Matthew Garrett <mjg59@...gle.com>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: James Morris <jmorris@...ei.org>,
LSM List <linux-security-module@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Howells <dhowells@...hat.com>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
"Naveen N . Rao" <naveen.n.rao@...ux.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
davem@...emloft.net
Subject: Re: [PATCH 22/27] Lock down kprobes
On Tue, Mar 26, 2019 at 5:30 AM Masami Hiramatsu <mhiramat@...nel.org> wrote:
>
> On Mon, 25 Mar 2019 15:09:49 -0700
> Matthew Garrett <matthewgarrett@...gle.com> wrote:
>
> > From: David Howells <dhowells@...hat.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.
Powered by blists - more mailing lists