Message-ID: <1345468396.2355.27.camel@falcor>
Date:	Mon, 20 Aug 2012 09:13:16 -0400
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Josh Boyer <jwboyer@...il.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 Mon, 2012-08-20 at 08:32 -0400, Josh Boyer wrote:
> On Sun, Aug 19, 2012 at 9:05 PM, Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:
> > On Fri, 2012-08-17 at 13:44 -0400, Josh Boyer wrote:
> >> On Fri, Aug 17, 2012 at 1:08 PM, Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:
> >> >> 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 ...
> >>
> >> For a developer, probably not often.  Though in reality, the usage of
> >> this by a single developer seems fair small.  A much wider, already
> >> existing usage is distribution kernel signing.
> >
> > This seems to be the real issue.  Do developers need to sign their own
> > builds?   Nobody is forcing the developer to enable signed modules.  If,
> > however, the developer decides to enforce signed modules, leaving the
> > private key lying around kind of defeats the purpose.
> 
> Right.  The issue is that you're making the kernel buildsystem do key
> management policy instead of trusting the developers using the keys
> mechanism to know what they're doing.
> 
> >> For a distribution kernel there are normally two cases:
> >>
> >> 1) Existing permanent company/distro key.  This is already handled.
> >> 2) per-kernel-build key (equivalent to your ephemeral key).  This would
> >> be handled fine if the key was generated if it didn't already exist and
> >> left alone.  The distro build system would remove it when it cleaned up
> >> the buildroot.
> >
> > Ok, I think we agree here, with the normal 'make', 'make modules_install
> > install', using an existing key or creating a new key if needed.
> >
> >> >> 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.
> >>
> >> Not if the buildsystem just made the key for them at 'make' time.  I'm
> >> still missing why it isn't done until 'modules_install' time.  Seems
> >> pretty sub-optimal.
> >
> > Using a private key that has been lying around for an unknown period of
> > time, kind of defeats the purpose.
> 
> Why is that?  Again, you're enforcing policy instead of leaving it up
> to the developers.  In the existing key case, you have no idea how long
> that key has been sitting around either, so I really see a disconnect
> between "existing company/private key" and "no key, create one for them
> during build time" cases.

Either the company build process, creates and cleans up after the build,
removing the private key, as you described above, or the "private key"
is held securely using an existing signing process (or some combination
of the two).

In the "no key, create one for them during build time", there is no
process in place cleaning up, other than the suggested new make target.

> >> > 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.
> >>
> >> I think the existence of an additional make target for signed modules
> >> is really confusing.  Particularly when you consider the target still
> >> exists even if the kernel isn't setup to work with signed modules.
> >
> > Ok, I see your concern.
> >
> >> If
> >> the config options are set, just have 'make modules_install' do it and
> >> create a key if one doesn't exist (or better yet, have 'make' do it).
> >
> > If creating the key is deferred to 'make modules_install', for the
> > reason given above or any other reason, the public key wasn't available
> > at the time the bzImage was created.  'make modules_install' would now
> > need to rebuild the bzImage.
> 
> Right, which is an utter pain and backwards.  That's why I suggested it
> be done at 'make' time.

Agreed, no doubt about it being a pain or backwards, but the solution
isn't to deny the problem, but to address it.  I'm open to
suggestions. :)

Mimi

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

Powered by blists - more mailing lists