mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Jones <pjones@redhat.com>
To: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 2/2] initramfs with digital signature protection
Date: Tue, 5 Feb 2013 13:03:00 -0500	[thread overview]
Message-ID: <20130205180300.GE2335@fenchurch.internal.datastacks.com> (raw)
In-Reply-To: <cc87f1242960fad1a9fb44bcec331915e14c832b.1360067333.git.dmitry.kasatkin@intel.com>

On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:
> Often initramfs is (re)fabricated on the machine on which it runs.
> In such cases it is impossible to sign initramfs image, because
> private key is not supposed to be available.

This doesn't address that problem at all.

> This patch adds support for additional digitaly signed initramfs images.
> Digitaly signed initramfs image can be loaded from conventional initramfs
> image or from rootfs and '/pre-init' is executed prior 'init' from initramfs
> or root file system. If 'pre-init' fails, kernel panics. Signed initramfs
> image must be located in '/initramfs-sig.img'.

So with this patch, you've effectively combined an unchecked initramfs with
a checked one that loads before it, and called the answer "secure".  This is
like S&P traunching a AAA mortgage with a DDD mortgage and calling it a
AAA CDO - the result isn't as good as what's claimed.

> Digitally signed initramfs can be used to provide protected user-space
> environment for initialization purpose. For example, LSM, IMA/EVM can be
> securely initialized using such approach.
> 
> Signing is done using scripts/sign-file from kernel source code and uses module
> signature format and module verification API. Important to note again that
> signing of such images should be done on the build machine.
> 
> Bellow is an example, how to sign compressed initrd (cpio) image:
> 
> scripts/sign-file -v signing_key.priv signing_key.x509 initrd.gz initramfs-sig.img

This means that if you've got multiple initramfs images, there's a signature
interleaved between them in the in-memory representation. We've used separate
images to separate invariant bits from e.g. plymouth from the initramfs that's
generated for each new kernel installed.  In general, it'd be nice to
keep multiple initramfs images working.

It's not clear to me why we need this encapsulation - wouldn't it be
better to add another [pointer,size] pair to the bootloader protocol
with a structure like:

struct {
	void *initramfs_area;
	size_t initramfs_area_len;
	void *signature;
	size_t signature_len;
};

And make that a list (all fields zero signifying the end).  That way we
can a) continue to easily support multiple initramfs images, b) allow
for /the whole initramfs to be checked/, which would be useful for e.g.
distro media?  If we really need a "parts of this are checked and parts
aren't" system, you could still allow policy to support that, but it's
not clear to me why that's a useful thing to have.

> @@ -895,6 +897,8 @@ static void __init kernel_init_freeable(void)
>  		prepare_namespace();
>  	}
>  
> +	initramfs_sig_load();
> +
>  	/*
>  	 * Ok, we have completed the initial bootup, and
>  	 * we're essentially up and running. Get rid of the

At the very least, this call should go in kernel_init() so that it's
logically after the comment you trimmed here about how we're about to
start userland running.

-- 
        Peter

  reply	other threads:[~2013-02-05 18:03 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-05 12:34 [RFC 0/2] " Dmitry Kasatkin
2013-02-05 12:34 ` [RFC 1/2] export unpack_to_rootfs Dmitry Kasatkin
2013-02-05 16:48   ` Peter Jones
2013-02-05 17:16     ` Kasatkin, Dmitry
2013-02-08  8:30       ` Kasatkin, Dmitry
2013-02-05 12:34 ` [RFC 2/2] initramfs with digital signature protection Dmitry Kasatkin
2013-02-05 18:03   ` Peter Jones [this message]
2013-02-05 20:08     ` Mimi Zohar
2013-02-05 22:03     ` Kasatkin, Dmitry
2013-02-05 18:19   ` Matthew Garrett
2013-02-05 18:30     ` Matthew Garrett
2013-02-05 18:34     ` Vivek Goyal
2013-02-05 21:55       ` Kasatkin, Dmitry
2013-04-05 13:50         ` Vivek Goyal
2013-04-08 19:43           ` Mimi Zohar
2013-04-08 20:09             ` Vivek Goyal
2013-04-08 20:17               ` Josh Boyer
2013-04-09 14:38                 ` Vivek Goyal
2013-04-10  3:07                   ` Mimi Zohar
2013-04-10 19:42                     ` Vivek Goyal
2013-04-10 21:05                       ` Mimi Zohar
2013-04-11  8:08                         ` Dmitry Kasatkin
2013-04-11 14:52                         ` Vivek Goyal
2013-04-12 11:54                           ` Mimi Zohar
     [not found]                         ` <CACE9dm-GZpjco8u6jNxLQpYA8LYSeoVjsyyRXVwxXHzjO-LvGw@mail.gmail.com>
2013-04-11 14:55                           ` Vivek Goyal
2013-04-11 18:42                             ` Dmitry Kasatkin
2013-04-11 21:13                               ` Vivek Goyal
2013-04-12 12:03                                 ` Mimi Zohar
2013-02-05 20:36   ` Peter Jones
2013-02-05 22:09     ` Kasatkin, Dmitry
2013-02-06  5:04       ` H. Peter Anvin
2013-02-06  8:01         ` Kasatkin, Dmitry
2013-02-06 16:41           ` H. Peter Anvin
2013-02-08  9:16             ` Kasatkin, Dmitry
2013-02-08 15:49               ` H. Peter Anvin
2013-02-08 16:24                 ` Kasatkin, Dmitry
2013-02-08 16:50                   ` H. Peter Anvin
2013-02-07 17:05   ` Vivek Goyal
2013-02-08  8:34     ` Kasatkin, Dmitry
2013-02-08 13:27       ` Kasatkin, Dmitry
2013-02-11 21:59         ` Vivek Goyal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130205180300.GE2335@fenchurch.internal.datastacks.com \
    --to=pjones@redhat.com \
    --cc=dmitry.kasatkin@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome