Re: [RFC v2 7/7] modsig: build rules and scripts to generate keysand sign modules

[Mimi Zohar]

On Fri, 2012-08-17 at 07:40 -0400, Josh Boyer wrote:
> On Thu, Aug 16, 2012 at 8:53 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> 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.

Ok.  Other than generating a key the first time, the normal development
build process now uses the same key, never requiring the developer to do
anything additional.  The developer controls the frequency the keys are
created/deleted.  I wonder how often that will be ...

> 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.

Sorry, I disagree.  Without the signed_modules_install target, the
developer would need to do each step manually - create new key, sign
modules, remove private key, and embed the new public key in the
bzImage.

I still think the signed_modules_install script, renamed to something
like ephemeral_signed_modules_install, is worthwhile and becomes a
convience tool for the developer, wanting to use ephemeral keys.  The
private key, in Dmitry's updated patches soon to be posted, will be
password protected with a random number, that is only accessible to the
current shell.

thanks,

Mimi

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