Message-ID: <20130205180300.GE2335@fenchurch.internal.datastacks.com>
Date:	Tue, 5 Feb 2013 13:03:00 -0500
From:	Peter Jones <pjones@...hat.com>
To:	Dmitry Kasatkin <dmitry.kasatkin@...el.com>
Cc:	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 2/2] initramfs with digital signature protection

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