linux-kernel - Re: [PATCH 00/23] Crypto keys and module signing

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]

Date:	Mon, 4 Jun 2012 09:38:43 -0400
From:	Josh Boyer <jwboyer@...il.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	David Howells <dhowells@...hat.com>, kyle@...artin.ca,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, keyrings@...ux-nfs.org
Subject: Re: [PATCH 00/23] Crypto keys and module signing

On Sun, Jun 3, 2012 at 9:16 PM, Rusty Russell <rusty@...tcorp.com.au> wrote:
>> > I had assumed you'd rather maintain a stable strip util which you can
>> > use on kernel modules than rework your module builds.  I guess not.
>>
>> Could you elaborate on this part a bit?  Do you mean integrate a
>> standalone strip utility in the kernel sources and maintain that for
>> use during module builds?  Or am I misunderstanding and you meant
>> something else?
>
> In the kernel sources, no.  But could RH maintain such a thing?  Surely.

Sure.  RH could continue to maintain the original modsign patch too.
I thought the point was to get the mechanism into the upstream kernel
so that it was generally available though.  Having the patches in the
mainline kernel but not the strip tool seems somewhat unhelpful.  I
would think such a tool would be part of the Kbuild infrastructure.

> Whether they want to guarantee that their strip is stable on kernel
> modules, or create a minimal 'kmod-strip' is up to them.
>
>> I can see how that sounds simple and desirable from one aspect, but
>> it seems somewhat odd to me to duplicate the existing (or create from
>> scratch) strip utilities.
>
> Mangling a module after it is signed is very odd, and odd things aren't
> nice for security features.  That's how we got here; I'm trying to move
> the oddness out of the verification path.

It's unfortunate, yes.  The biggest case I can think of is splitting
the debug symbols out of the modules after they are built (David might
have other cases).  Perhaps we could upstream that as well and
organize it such that the modules are built, split for debuginfo, and
then signed?

josh
--
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/