linux-kernel - Re: [RFC v2 7/7] modsig: build rules and scripts to generate keys and sign modules

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: <CA+5PVA7ffHv7xOom1SNN8=-qYUQAUnHNXi=TNSX_FcKPUBtgzw@mail.gmail.com>
Date:	Fri, 17 Aug 2012 07:40:07 -0400
From:	Josh Boyer <jwboyer@...il.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>, jmorris@...ei.org,
	rusty@...tcorp.com.au, dhowells@...hat.com,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC v2 7/7] modsig: build rules and scripts to generate keys and
 sign modules

On Thu, Aug 16, 2012 at 8:53 PM, Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:
>> >> The reason for "signed_modules_install" is to limit existence of private key.
>> >> Private key is generate just before install, modules installed and
>> >> signed, then key is destroyed.
>> >> So existence of private key is limited to "time make
>> >> signed_modules_install" execution time.
>> >>
>> >> We had a debate about it, and strong message was that we might want to
>> >> do it like that...
>> >
>> > I guess I personally don't see the need to destroy they key so quickly.
>> > Is the concern that an intruder might grab the key and use it to sign a
>> > module that the developer would then later on somehow load?  Or
>> > similarly someone would grab a temporary key from a distro build
>> > machine?  That limits the attack surface, sure, but I'm not sure it's
>> > really reasonable.
>> >
>> > For a developer that isn't distributing kernels to others, it's just
>> > adding more time to the compile (which I know can be disabled, but
>> > still).  For a distribution, most of them are either using a private
>> > key already or they have a buildsystem that destroys a buildroot after
>> > a build completes.  The key is already going to be destroyed in that
>> > scenario.
>> >
>> > josh
>>
>> Well... Will not argue here. I had similar opinion as well.
>>
>> Mimi strongly wanted really to "reduce" the existence time of the key...
>
> The options are creating the key during 'make' or 'make
> modules_install'.  If you create the key during 'make', then you have no
> way of knowing whether or not it is a persistent or ephemeral key, and
> whether it should be deleted after signing the modules.

The buildsystem doesn't really _need_ to know that though.

> You could create a persistent key using 'make genkey', before 'make',
> and never delete the private key.  Then there wouldn't be any
> overhead. :)  If 'CONFIG_INTEGRITY_MODULE' is configured, 'make
> modules_install' would use the existing key.
>
> 'make signed_modules_install' would be for creating and using ephemeral
> keys.
>
> What do you think?

I don't see a need for the kernel make system to ever delete a key.
If one doesn't exist, it should create one if the config options are
set and leave it alone entirely after that.  If one exists already,
then it should leave it alone as it already does.

If you really want to enforce ephemeral keys in the make system, then
doing it via 'make clean' or 'make distclean' would make more sense to
me.  But I personally think key management is something the developers
or distros should be handling on their own.  Creating a key for them is
a convenience so it's worthwhile, but removing it should be done by
them.

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/