lkml.org 
[lkml]   [2015]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 10/8] modsign: Allow password to be specified for signing key
    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


    \
     
     \ /
      Last update: 2015-05-19 19:21    [W:3.572 / U:0.484 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site