From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932511AbbESQfH (ORCPT ); Tue, 19 May 2015 12:35:07 -0400 Received: from lan.nucleusys.com ([92.247.61.126]:41642 "EHLO zztop.nucleusys.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932151AbbESQfE (ORCPT ); Tue, 19 May 2015 12:35:04 -0400 Date: Tue, 19 May 2015 19:34:27 +0300 From: Petko Manolov To: David Woodhouse Cc: dhowells@redhat.com, rusty@rustcorp.com.au, mmarek@suse.cz, mjg59@srcf.ucam.org, keyrings@linux-nfs.org, dmitry.kasatkin@gmail.com, mcgrof@suse.com, linux-kernel@vger.kernel.org, seth.forshee@canonical.com, linux-security-module@vger.kernel.org Subject: Re: [PATCH 10/8] modsign: Allow password to be specified for signing key Message-ID: <20150519163427.GA7718@localhost> Mail-Followup-To: David Woodhouse , dhowells@redhat.com, rusty@rustcorp.com.au, mmarek@suse.cz, mjg59@srcf.ucam.org, keyrings@linux-nfs.org, dmitry.kasatkin@gmail.com, mcgrof@suse.com, linux-kernel@vger.kernel.org, seth.forshee@canonical.com, linux-security-module@vger.kernel.org References: <20150515123513.16723.96340.stgit@warthog.procyon.org.uk> <1432046758.3277.36.camel@infradead.org> <20150519155010.GA7549@localhost> <1432052112.3277.66.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432052112.3277.66.camel@infradead.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -1.0 (-) X-Spam-Report: Spam detection software, running on the system "zztop.nucleusys.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 15-05-19 17:15:12, David Woodhouse wrote: > On Tue, 2015-05-19 at 18:50 +0300, Petko Manolov wrote: > > On 15-05-19 15:45:58, David Woodhouse wrote: > > > We don't want this in the Kconfig since it might then get exposed in > > > /proc/config.gz. So make it a parameter to Kbuild instead. This also > > > means we don't have to jump through hoops to strip quotes from it, as > > > we would if it was a config option. > > > > If it were on a network-less, secure sign/build server i'd say it is OK. > > > > However, exposing your private key's password in an environment variable on a > > regular Linux box is a bit fishy. > > I don't quite understand the objection. > > If you want the modules to be signed with an external key of your > choice, then for the duration of the 'make modules_sign' run (or 'make > modules_install if CONFIG_MODULE_SIG_ALL=y) surely the password has to > be available *somehow*? > > You are, of course, free to sign the modules by invoking sign-file > directly. In which case you *still* need to provide it with the password > for the key somehow, if there is one. > > Mimi quite rightly pointed out that my original mechanism for this, a > CONFIG_MODULE_SIG_KEY_PASSWORD option, was inadvertently exposing it > more than was necessary. > > As it is now, you *only* need it in the environment for the duration of > the operations that actually *use* it. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15-05-19 17:15:12, David Woodhouse wrote: > On Tue, 2015-05-19 at 18:50 +0300, Petko Manolov wrote: > > On 15-05-19 15:45:58, David Woodhouse wrote: > > > We don't want this in the Kconfig since it might then get exposed in > > > /proc/config.gz. So make it a parameter to Kbuild instead. This also > > > means we don't have to jump through hoops to strip quotes from it, as > > > we would if it was a config option. > > > > If it were on a network-less, secure sign/build server i'd say it is OK. > > > > However, exposing your private key's password in an environment variable on a > > regular Linux box is a bit fishy. > > I don't quite understand the objection. > > If you want the modules to be signed with an external key of your > choice, then for the duration of the 'make modules_sign' run (or 'make > modules_install if CONFIG_MODULE_SIG_ALL=y) surely the password has to > be available *somehow*? > > You are, of course, free to sign the modules by invoking sign-file > directly. In which case you *still* need to provide it with the password > for the key somehow, if there is one. > > Mimi quite rightly pointed out that my original mechanism for this, a > CONFIG_MODULE_SIG_KEY_PASSWORD option, was inadvertently exposing it > more than was necessary. > > As it is now, you *only* need it in the environment for the duration of > the operations that actually *use* it. As with everything there is bad and good side to your proposal. bad: - password in environment variable _could_ be very dangerous; - someone is bound to misuse this feature sooner or later; good: - the actual risk is mitigated as the key is very short-lived; - the feature is going to be used by a small number of people; - does not break automated builds, maybe; - there is an alternative for those who want more secure approach; > Do you have a better suggestion? *better* is a matter of prospective. Security and convenience are at the wrong side of the spectrum relative to each other. :) Don't get me wrong, your patch is perhaps the lesser evil. I just wanted to bring up my concerns. cheers, Petko