lkml.org 
[lkml]   [2013]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH V3 08/11] kexec: Disable at runtime if the kernel enforces module loading restrictions
From
Date
On Sun, 2013-09-08 at 17:15 +0000, 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 one and it doesn't. They use it for
> > support to tell if you've been adhering to your contract. That use case
> > has nothing to do with security.
>
> That use case has nothing to do with this patch, either. It's completely
> unaffected. This only triggers if the kernel is configured to refuse the
> loading of unsigned modules.
>
> > The analogy is rubbish. I can give away CAP_SYS_MODULE and enforce what
> > modules those I've given the permission to can insert by signing them.
> > I keep CAP_SYS_BOOT, so they can't use kexec to subvert this.
>
> Yeah, that's a good argument for why capabilities are mostly pointless.
> If I have CAP_SYS_BOOT I can give myself any other capabilities. Why
> bother?

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 not into my house to steal the silver ... saying CAP_SYS_BOOT
is too powerful doesn't affect that use case because I haven't given
away CAP_SYS_BOOT.

James



\
 
 \ /
  Last update: 2013-09-08 20:01    [W:0.094 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site