linux-kernel - Re: [RFC] module: signature infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1346852077.2389.7.camel@falcor>
Date:	Wed, 05 Sep 2012 09:34:37 -0400
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>,
	David Howells <dhowells@...hat.com>, jmorris@...ei.org,
	keyrings@...ux-nfs.org, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] module: signature infrastructure

On Wed, 2012-09-05 at 09:59 +0930, Rusty Russell wrote:
> "Kasatkin, Dmitry" <dmitry.kasatkin@...el.com> writes:
> > Hi,
> >
> > Please read bellow...
> >
> > On Tue, Sep 4, 2012 at 8:55 AM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> >> OK, I took a look at the module.c parts of David and Dmitry's patchsets,
> >> and didn't really like either, but I stole parts of David's to make
> >> this.
> >>
> >> So, here's the module.c part of module signing.  I hope you two got time
> >> to discuss the signature format details?  Mimi suggested a scheme where
> >> the private key would never be saved on disk (even temporarily), but I
> >> didn't see patches.  Frankly it's something we can do later; let's aim
> >> at getting the format right for the next merge window.
> >
> > In our patches key is stored on the disc in encrypted format...
> 
> Oh, I missed that twist.  Thanks for the explanation.
> 
> On consideration, I prefer signing to be the final part of the "modules"
> target rather than modules_install.  I run the latter as root, and that
> is wrong for doing any code generation.

Agreed, but keep in mind that 'modules_install' could subsequently strip
the module.

Mimi

> >> +       for (i = 0; i < *len - (sizeof(MODULE_SIG_STRING)-1); i++) {
> >> +               /* Our memcmp is dumb, speed it up a little. */
> >> +               if (((char *)mod)[i] != MODULE_SIG_STRING[0])
> >> +                       continue;
> >> +               if (memcmp(mod, MODULE_SIG_STRING, strlen(MODULE_SIG_STRING)))
> >
> > should be (mod+i)?
> 
> Yes, indeed.  Thanks, fixed.
> 
> >> +                       continue;
> >> +
> >> +               sig = mod + i + strlen(MODULE_SIG_STRING);
> >> +               siglen = *len - i - strlen(MODULE_SIG_STRING);
> >> +               *len = i;
> >> +               break;
> >> +       }
> >
> > In general please clarify why do you need such parsing at all?
> > Why not to have MODULE_SIG_STRING as a last octets of the module and
> > have signature length field before?
> > Then it is easy to get the signature and rest of the module?
> > That will be super fast...
> >
> > Please clarify.
> 
> Ignore performance, it's just not an issue here.  So the simplest code
> wins.
> 
> And it's also simpler to sign a module this way.
> 
>         (echo '~Module signature appended~'; gpg --sign ....) >> mod.ko
> 
> Cheers,
> Rusty.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/