On Sun, 2013-09-08 at 10:32 -0700, James Bottomley wrote:
> On Sun, 2013-09-08 at 17:27 +, Matthew Garrett wrote:
> > > It's an argument that CAP_SYS_BOOT is too powerful yes, but if you
> > > recall, I said I keep that one. In the rather lame analogy, what I do
> > > by giving away CAP_SYS_MO
On Sun, 2013-09-08 at 17:27 +, Matthew Garrett wrote:
> > It's an argument that CAP_SYS_BOOT is too powerful yes, but if you
> > recall, I said I keep that one. In the rather lame analogy, what I do
> > by giving away CAP_SYS_MODULE and enforcing module signing while keeping
> > CAP_SYS_BOOT i
> It's an argument that CAP_SYS_BOOT is too powerful yes, but if you
> recall, I said I keep that one. In the rather lame analogy, what I do
> by giving away CAP_SYS_MODULE and enforcing module signing while keeping
> CAP_SYS_BOOT is allow people into my conservatory to play with the
> plants but
On Sun, 2013-09-08 at 10:22 -0700, Greg KH wrote:
> On Sun, Sep 08, 2013 at 04:59:40PM +, Matthew Garrett wrote:
> > On Sun, 2013-09-08 at 09:39 -0700, Greg KH wrote:
> >
> > > But I want, for other reasons (i.e. safety in layers), signed kernel
> > > modules. I also might actually want some
On Sun, 2013-09-08 at 17:15 +, Matthew Garrett wrote:
> On Sun, 2013-09-08 at 10:11 -0700, James Bottomley wrote:
>
> > That's not true if you look at the use cases. Distros use signed
> > modules to taint the kernel: insert an unsigned one and the kernel
> > taints; insert a properly signed
On Sun, Sep 08, 2013 at 04:59:40PM +, Matthew Garrett wrote:
> On Sun, 2013-09-08 at 09:39 -0700, Greg KH wrote:
>
> > But I want, for other reasons (i.e. safety in layers), signed kernel
> > modules. I also might actually want some debugfs files in some random
> > driver (like this series re
On Sun, 2013-09-08 at 10:11 -0700, James Bottomley wrote:
> That's not true if you look at the use cases. Distros use signed
> modules to taint the kernel: insert an unsigned one and the kernel
> taints; insert a properly signed one and it doesn't. They use it for
> support to tell if you've be
On Sun, 2013-09-08 at 08:51 -0700, Kees Cook wrote:
> On Sun, Sep 8, 2013 at 12:24 AM, Greg KH wrote:
> > On Sun, Sep 08, 2013 at 06:44:08AM +, Matthew Garrett wrote:
> >> On Sat, 2013-09-07 at 23:40 -0700, Greg KH wrote:
> >> > If you apply this, you break everyone who is currently relying on
On Sun, 2013-09-08 at 09:39 -0700, Greg KH wrote:
> But I want, for other reasons (i.e. safety in layers), signed kernel
> modules. I also might actually want some debugfs files in some random
> driver (like this series removes).
You want a configuration that makes no sense. There's no reason th
On Sun, Sep 08, 2013 at 04:24:47PM +, Matthew Garrett wrote:
> On Sun, 2013-09-08 at 09:18 -0700, Greg KH wrote:
>
> > I want both, but I don't need signed kexec support because I want to use
> > kexec for a program that I "know" is correct because I validated the
> > disk image it was on befo
On Sun, 2013-09-08 at 09:18 -0700, Greg KH wrote:
> I want both, but I don't need signed kexec support because I want to use
> kexec for a program that I "know" is correct because I validated the
> disk image it was on before I mounted it. We already have other ways to
> "verify" things without h
On Sun, Sep 08, 2013 at 08:51:27AM -0700, Kees Cook wrote:
> On Sun, Sep 8, 2013 at 12:24 AM, Greg KH wrote:
> > On Sun, Sep 08, 2013 at 06:44:08AM +, Matthew Garrett wrote:
> >> On Sat, 2013-09-07 at 23:40 -0700, Greg KH wrote:
> >> > If you apply this, you break everyone who is currently rel
On Sun, Sep 8, 2013 at 12:24 AM, Greg KH wrote:
> On Sun, Sep 08, 2013 at 06:44:08AM +, Matthew Garrett wrote:
>> On Sat, 2013-09-07 at 23:40 -0700, Greg KH wrote:
>> > If you apply this, you break everyone who is currently relying on kexec
>> > (i.e. kdump, bootloaders, etc.), from using sign
On Sun, 2013-09-08 at 00:24 -0700, Greg KH wrote:
> On Sun, Sep 08, 2013 at 06:44:08AM +, Matthew Garrett wrote:
> > At the most trivial level, grab the address of sig_enforce from
> > kallsyms, jump to a kernel that doesn't enforce STRICT_DEVMEM, modify
> > sig_enforce, jump back to the old k
On Sun, Sep 08, 2013 at 06:44:08AM +, Matthew Garrett wrote:
> On Sat, 2013-09-07 at 23:40 -0700, Greg KH wrote:
> > On Tue, Sep 03, 2013 at 07:50:15PM -0400, Matthew Garrett wrote:
> > > kexec permits the loading and execution of arbitrary code in ring 0, which
> > > is something that module s
On Sat, 2013-09-07 at 23:40 -0700, Greg KH wrote:
> On Tue, Sep 03, 2013 at 07:50:15PM -0400, Matthew Garrett wrote:
> > kexec permits the loading and execution of arbitrary code in ring 0, which
> > is something that module signing enforcement is meant to prevent. It makes
> > sense to disable kex
On Tue, Sep 03, 2013 at 07:50:15PM -0400, Matthew Garrett wrote:
> kexec permits the loading and execution of arbitrary code in ring 0, which
> is something that module signing enforcement is meant to prevent. It makes
> sense to disable kexec in this situation.
I see no match between kexec and si
On Wed, 2013-09-04 at 14:09 -0600, jerry.hoem...@hp.com wrote:
> On Tue, Sep 03, 2013 at 07:50:15PM -0400, Matthew Garrett wrote:
> > kexec permits the loading and execution of arbitrary code in ring 0, which
> > is something that module signing enforcement is meant to prevent. It makes
> > sense t
On Tue, Sep 03, 2013 at 07:50:15PM -0400, Matthew Garrett wrote:
> kexec permits the loading and execution of arbitrary code in ring 0, which
> is something that module signing enforcement is meant to prevent. It makes
> sense to disable kexec in this situation.
>
> Signed-off-by: Matthew Garrett
On Wed, Sep 4, 2013 at 4:09 PM, wrote:
> On Tue, Sep 03, 2013 at 07:50:15PM -0400, Matthew Garrett wrote:
>> kexec permits the loading and execution of arbitrary code in ring 0, which
>> is something that module signing enforcement is meant to prevent. It makes
>> sense to disable kexec in this s
On Tue, 3 Sep 2013, Matthew Garrett wrote:
> kexec permits the loading and execution of arbitrary code in ring 0, which
> is something that module signing enforcement is meant to prevent. It makes
> sense to disable kexec in this situation.
>
> Signed-off-by: Matthew Garrett
Reviewed-by: James
kexec permits the loading and execution of arbitrary code in ring 0, which
is something that module signing enforcement is meant to prevent. It makes
sense to disable kexec in this situation.
Signed-off-by: Matthew Garrett
---
kernel/kexec.c | 8
1 file changed, 8 insertions(+)
diff --
22 matches
Mail list logo
