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: <1345424724.2384.15.camel@falcor>
Date:	Sun, 19 Aug 2012 21:05:24 -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 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. 

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

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

thanks,

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/