[RFC 0/2] initramfs with digital signature protection

[RFC 0/2] initramfs with digital signature protection

[Dmitry Kasatkin]

This an RFC for the signed initramfs images, which can be used to provide
verified initial user-space. Please read patch description for the detailed
explanation.

BR,
Dmitry

Dmitry Kasatkin (2):
  export unpack_to_rootfs
  initramfs with digital signature protection

 init/Kconfig         |    7 +++
 init/Makefile        |    1 +
 init/do_mounts.h     |   12 ++++
 init/initramfs.c     |    2 +-
 init/initramfs_sig.c |  171 ++++++++++++++++++++++++++++++++++++++++++++++++++
 init/main.c          |    4 ++
 6 files changed, 196 insertions(+), 1 deletion(-)
 create mode 100644 init/initramfs_sig.c

-- 
1.7.10.4

[RFC 1/2] export unpack_to_rootfs

[Dmitry Kasatkin]

Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
---
 init/do_mounts.h |    2 ++
 init/initramfs.c |    2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/init/do_mounts.h b/init/do_mounts.h
index f5b978a..11829eb 100644
--- a/init/do_mounts.h
+++ b/init/do_mounts.h
@@ -74,3 +74,5 @@ void md_run_setup(void);
 static inline void md_run_setup(void) {}
 
 #endif
+
+char * __init unpack_to_rootfs(char *buf, unsigned len);
diff --git a/init/initramfs.c b/init/initramfs.c
index 84c6bf1..e32bc06 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -421,7 +421,7 @@ static unsigned my_inptr;   /* index of next byte to be processed in inbuf */
 
 #include <linux/decompress/generic.h>
 
-static char * __init unpack_to_rootfs(char *buf, unsigned len)
+char * __init unpack_to_rootfs(char *buf, unsigned len)
 {
 	int written, res;
 	decompress_fn decompress;
-- 
1.7.10.4

Re: [RFC 1/2] export unpack_to_rootfs

[Peter Jones]

On Tue, Feb 05, 2013 at 02:34:49PM +0200, Dmitry Kasatkin wrote:
> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
> ---
>  init/do_mounts.h |    2 ++
>  init/initramfs.c |    2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/init/do_mounts.h b/init/do_mounts.h
> index f5b978a..11829eb 100644
> --- a/init/do_mounts.h
> +++ b/init/do_mounts.h
> @@ -74,3 +74,5 @@ void md_run_setup(void);
>  static inline void md_run_setup(void) {}
>  
>  #endif
> +
> +char * __init unpack_to_rootfs(char *buf, unsigned len);
> diff --git a/init/initramfs.c b/init/initramfs.c
> index 84c6bf1..e32bc06 100644
> --- a/init/initramfs.c
> +++ b/init/initramfs.c
> @@ -421,7 +421,7 @@ static unsigned my_inptr;   /* index of next byte to be processed in inbuf */
>  
>  #include <linux/decompress/generic.h>
>  
> -static char * __init unpack_to_rootfs(char *buf, unsigned len)
> +char * __init unpack_to_rootfs(char *buf, unsigned len)
>  {
>  	int written, res;
>  	decompress_fn decompress;

Doing this unconditionally seems to be inviting rootkit authors to use a
new and shiny tool.  I also don't think it's the best way to do this,
but I'll comment on the other patch to explain why.

-- 
        Peter

Re: [RFC 1/2] export unpack_to_rootfs

[Kasatkin, Dmitry]

On Tue, Feb 5, 2013 at 6:48 PM, Peter Jones <pjones@redhat.com> wrote:
> On Tue, Feb 05, 2013 at 02:34:49PM +0200, Dmitry Kasatkin wrote:
>> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
>> ---
>>  init/do_mounts.h |    2 ++
>>  init/initramfs.c |    2 +-
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/init/do_mounts.h b/init/do_mounts.h
>> index f5b978a..11829eb 100644
>> --- a/init/do_mounts.h
>> +++ b/init/do_mounts.h
>> @@ -74,3 +74,5 @@ void md_run_setup(void);
>>  static inline void md_run_setup(void) {}
>>
>>  #endif
>> +
>> +char * __init unpack_to_rootfs(char *buf, unsigned len);
>> diff --git a/init/initramfs.c b/init/initramfs.c
>> index 84c6bf1..e32bc06 100644
>> --- a/init/initramfs.c
>> +++ b/init/initramfs.c
>> @@ -421,7 +421,7 @@ static unsigned my_inptr;   /* index of next byte to be processed in inbuf */
>>
>>  #include <linux/decompress/generic.h>
>>
>> -static char * __init unpack_to_rootfs(char *buf, unsigned len)
>> +char * __init unpack_to_rootfs(char *buf, unsigned len)
>>  {
>>       int written, res;
>>       decompress_fn decompress;
>
> Doing this unconditionally seems to be inviting rootkit authors to use a
> new and shiny tool.  I also don't think it's the best way to do this,
> but I'll comment on the other patch to explain why.
>

Sorry for re-post, but answering from mobile was in HTML and it was blocked.
Modifying an initramfs gives the same opportunity during boot only.
But agreed, it might be the part of the primary source code. It was
very to do it in this way to implement and test a solution.

Thanks.

> --
>         Peter

Re: [RFC 1/2] export unpack_to_rootfs

[Kasatkin, Dmitry]

On Tue, Feb 5, 2013 at 7:16 PM, Kasatkin, Dmitry
<dmitry.kasatkin@intel.com> wrote:
> On Tue, Feb 5, 2013 at 6:48 PM, Peter Jones <pjones@redhat.com> wrote:
>> On Tue, Feb 05, 2013 at 02:34:49PM +0200, Dmitry Kasatkin wrote:
>>> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
>>> ---
>>>  init/do_mounts.h |    2 ++
>>>  init/initramfs.c |    2 +-
>>>  2 files changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/init/do_mounts.h b/init/do_mounts.h
>>> index f5b978a..11829eb 100644
>>> --- a/init/do_mounts.h
>>> +++ b/init/do_mounts.h
>>> @@ -74,3 +74,5 @@ void md_run_setup(void);
>>>  static inline void md_run_setup(void) {}
>>>
>>>  #endif
>>> +
>>> +char * __init unpack_to_rootfs(char *buf, unsigned len);
>>> diff --git a/init/initramfs.c b/init/initramfs.c
>>> index 84c6bf1..e32bc06 100644
>>> --- a/init/initramfs.c
>>> +++ b/init/initramfs.c
>>> @@ -421,7 +421,7 @@ static unsigned my_inptr;   /* index of next byte to be processed in inbuf */
>>>
>>>  #include <linux/decompress/generic.h>
>>>
>>> -static char * __init unpack_to_rootfs(char *buf, unsigned len)
>>> +char * __init unpack_to_rootfs(char *buf, unsigned len)
>>>  {
>>>       int written, res;
>>>       decompress_fn decompress;
>>
>> Doing this unconditionally seems to be inviting rootkit authors to use a
>> new and shiny tool.  I also don't think it's the best way to do this,
>> but I'll comment on the other patch to explain why.
>>
>

Just wanted to point out, that there is no chance for rootkits in
anyway because of this:

1) "rootkits" can have unpacking functionality inside, but if they are so lazy
2) unpack_to_rootfs() is not EXPORT_SYMBOLed.
3) and more over, unpack_to_rootfs() is "__init" and is freed before
main initramfs or rootfs init is executed.

- Dmitry

> Sorry for re-post, but answering from mobile was in HTML and it was blocked.
> Modifying an initramfs gives the same opportunity during boot only.
> But agreed, it might be the part of the primary source code. It was
> very to do it in this way to implement and test a solution.
>
> Thanks.
>
>> --
>>         Peter

[RFC 2/2] initramfs with digital signature protection

[Dmitry Kasatkin]

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

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

When using initramfs-tools, initramfs-sig.img can be easily included into the
conventional initramfs using initramfs-tools hooks, for example, by creating
/etc/initramfs-tools/hooks/initramfs_sig.sh, and adding following lines there:

  #!/bin/sh
  . /usr/share/initramfs-tools/hook-functions
  copy_exec /initramfs-sig.img

Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
---
 init/Kconfig         |    7 +++
 init/Makefile        |    1 +
 init/do_mounts.h     |   10 +++
 init/initramfs_sig.c |  171 ++++++++++++++++++++++++++++++++++++++++++++++++++
 init/main.c          |    4 ++
 5 files changed, 193 insertions(+)
 create mode 100644 init/initramfs_sig.c

diff --git a/init/Kconfig b/init/Kconfig
index 7d30240..fca6f47 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1738,4 +1738,11 @@ config ASN1
 	  inform it as to what tags are to be expected in a stream and what
 	  functions to call on what tags.
 
+config INITRAMFS_SIG
+	bool "initramfs with digital signature protection"
+	depends on INTEGRITY_ASYMMETRIC_KEYS
+	default n
+	help
+	  This option enables initramfs with digital signature protection.
+
 source "kernel/Kconfig.locks"
diff --git a/init/Makefile b/init/Makefile
index 7bc47ee..0099169 100644
--- a/init/Makefile
+++ b/init/Makefile
@@ -7,6 +7,7 @@ ifneq ($(CONFIG_BLK_DEV_INITRD),y)
 obj-y                          += noinitramfs.o
 else
 obj-$(CONFIG_BLK_DEV_INITRD)   += initramfs.o
+obj-$(CONFIG_INITRAMFS_SIG)   += initramfs_sig.o
 endif
 obj-$(CONFIG_GENERIC_CALIBRATE_DELAY) += calibrate.o
 
diff --git a/init/do_mounts.h b/init/do_mounts.h
index 11829eb..113207f 100644
--- a/init/do_mounts.h
+++ b/init/do_mounts.h
@@ -76,3 +76,13 @@ static inline void md_run_setup(void) {}
 #endif
 
 char * __init unpack_to_rootfs(char *buf, unsigned len);
+
+#ifdef CONFIG_INITRAMFS_SIG
+
+int __init initramfs_sig_load(void);
+
+#else
+
+static inline int initramfs_sig_load(void) { return 0; }
+
+#endif
diff --git a/init/initramfs_sig.c b/init/initramfs_sig.c
new file mode 100644
index 0000000..b65f97e
--- /dev/null
+++ b/init/initramfs_sig.c
@@ -0,0 +1,171 @@
+/*
+ * Copyright (C) 2013 Intel Corporation
+ *
+ * Author:
+ * Dmitry Kasatkin <dmitry.kasatkin@intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, version 2 of the License.
+ *
+ */
+
+#define pr_fmt(fmt) "initramfs_sig: " fmt
+
+/*
+ * Many of the syscalls used in this file expect some of the arguments
+ * to be __user pointers not __kernel pointers.  To limit the sparse
+ * noise, turn off sparse checking for this file.
+ */
+
+#ifdef __CHECKER__
+#undef __CHECKER__
+#warning "Sparse checking disabled for this file"
+#endif
+
+#include <linux/unistd.h>
+#include <linux/kernel.h>
+#include <linux/fs.h>
+#include <linux/sched.h>
+#include <linux/freezer.h>
+#include <linux/kmod.h>
+#include <linux/module.h>
+
+#include "../kernel/module-internal.h"
+#include "do_mounts.h"
+
+#define BUF_SIZE	BLOCK_SIZE
+
+static const char *secmnt = "/root";
+static const char *initramfs_img = "/initramfs-sig.img";
+
+static int __init load_image(const char *from)
+{
+	int err = -EINVAL, fd;
+	char *buf = NULL, *msg;
+	off_t len, offset;
+	int size = BLOCK_SIZE;
+	const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
+
+	fd = sys_open(from, O_RDONLY, 0);
+	if (fd < 0) {
+		pr_err("cannot open %s: %d\n", from, fd);
+		return fd;
+	}
+
+	len = sys_lseek(fd, 0, SEEK_END);
+	pr_info("%s image size: %lu\n", from, len);
+	if (len < 0)
+		goto out;
+
+	buf = vmalloc(len);
+	if (!buf) {
+		pr_err("unable to allocate large block of memory\n");
+		err = -ENOMEM;
+		goto out_close;
+	}
+
+	sys_lseek(fd, 0, SEEK_SET);
+
+	for (offset = 0; len; offset += size, len -= size) {
+		if (len < size)
+			size = len;
+		if (sys_read(fd, buf + offset, size) != size)
+			goto out;
+	}
+
+	pr_info("image offset: %lu\n", offset);
+
+	offset -= markerlen;
+
+	if (offset < 0 || memcmp(buf + offset, MODULE_SIG_STRING, markerlen)) {
+		pr_err("image has no marker\n");
+		goto out;
+	}
+
+	err = mod_verify_sig(buf, &offset);
+	pr_info("mod_verify_sig() = %d, len: %lu\n", err, offset);
+	if (err)
+		goto out;
+
+	err = sys_mount("tpmfs", (char *)secmnt, "tmpfs", MS_SILENT, NULL);
+	if (err) {
+		pr_err("sys_mount() = %d\n", err);
+		goto out;
+	}
+
+	sys_unshare(CLONE_FS | CLONE_FILES);
+	sys_chdir(secmnt);
+	sys_chroot(".");
+	sys_setsid();
+
+	pr_info("unpack start\n");
+	msg = unpack_to_rootfs(buf, offset);
+	if (msg) {
+		pr_err("unable to unpack rootfs\n");
+		err = -EINVAL;
+		goto out;
+	}
+	pr_info("unpack end\n");
+
+	err = 0;
+
+out:
+	vfree(buf);
+out_close:
+	sys_close(fd);
+
+	return err;
+}
+
+static int __init init_init(struct subprocess_info *info, struct cred *new)
+{
+	return load_image(initramfs_img);
+}
+
+static void init_cleanup(struct subprocess_info *info)
+{
+	int err;
+
+	pr_info("cleanup\n");
+
+	err = sys_umount((char *)secmnt, MNT_DETACH);
+	if (err)
+		pr_err("unable to umount secmnt: %d\n", err);
+}
+
+static int __init load_initramfs(void)
+{
+	static char *argv[] = { "pre-init", NULL, };
+	extern char *envp_init[];
+	int err;
+
+	/*
+	 * In case that a resume from disk is carried out by linuxrc or one of
+	 * its children, we need to tell the freezer not to wait for us.
+	 */
+	current->flags |= PF_FREEZER_SKIP;
+
+	err = call_usermodehelper_fns("/pre-init", argv, envp_init,
+				      UMH_WAIT_PROC, init_init, init_cleanup,
+				      NULL);
+
+	current->flags &= ~PF_FREEZER_SKIP;
+
+	pr_info("initramfs_sig /pre-init completed: %d\n", err);
+
+	return err;
+}
+
+int __init initramfs_sig_load(void)
+{
+	if (sys_access(initramfs_img, 0))
+		panic("signed initramfs image not found (INITRAMFS_SIG is anabled)\n");
+
+	if (load_initramfs())
+		panic("initramfs_sig failed! (INITRAMFS_SIG is anabled)\n");
+
+	pr_info("initramfs_sig finished\n");
+
+	return 0;
+}
diff --git a/init/main.c b/init/main.c
index 85d69df..43ef145 100644
--- a/init/main.c
+++ b/init/main.c
@@ -81,6 +81,8 @@
 #include <asm/smp.h>
 #endif
 
+#include "do_mounts.h"
+
 static int kernel_init(void *);
 
 extern void init_IRQ(void);
@@ -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
-- 
1.7.10.4

Re: [RFC 2/2] initramfs with digital signature protection

[Peter Jones]

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

Re: [RFC 2/2] initramfs with digital signature protection

[Mimi Zohar]

On Tue, 2013-02-05 at 13:03 -0500, Peter Jones wrote:

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

https://lkml.org/lkml/2013/1/30/68 was in response to the assumption
that the initramfs is measured/appraised.  These patches attempt to
address those concerns.

Mimi

Re: [RFC 2/2] initramfs with digital signature protection

[Kasatkin, Dmitry]

On Tue, Feb 5, 2013 at 8:03 PM, Peter Jones <pjones@redhat.com> wrote:
> 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.
>

Does not address what?

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

This is absolutely wrong example. I do not understand your point at all.
Signed image is loaded, verified and executed before any content from unsigned.
What is the problem here?

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

I cannot get you.
There are multiple inittamfs images. But in addition, there is a
signed image, which contains
special stuff to initialize secure bits of the platform. After that,
LSM or IMA/EVM could do its job.

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

Yes, it can be done in this way as well. I wanted to get fast working
solution to have a discussion
and ideas.

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

Yes. it is possible to call it before free_initmem()...

Thanks,
Dmitry

>
> --
>         Peter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/2] initramfs with digital signature protection

[Matthew Garrett]

On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:

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

What stops an attacker from simply removing the signed image from the 
initramfs and running modified versions of the same tools from the 
unsigned image?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC 2/2] initramfs with digital signature protection

[Matthew Garrett]

On Tue, Feb 05, 2013 at 06:19:26PM +0000, Matthew Garrett wrote:
> On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:
> 
> > 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.
> 
> What stops an attacker from simply removing the signed image from the 
> initramfs and running modified versions of the same tools from the 
> unsigned image?

I'm sorry, ignore that - if the kernel's configured to do this, it'll 
panic if it can't find the signed image. Ok.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC 2/2] initramfs with digital signature protection

[Vivek Goyal]

On Tue, Feb 05, 2013 at 06:19:26PM +0000, Matthew Garrett wrote:
> On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:
> 
> > 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.
> 
> What stops an attacker from simply removing the signed image from the 
> initramfs and running modified versions of the same tools from the 
> unsigned image?

Looks like having signed initramfs image is mandatory otherwise system
panics.

+	if (sys_access(initramfs_img, 0))
+               panic("signed initramfs image not found (INITRAMFS_SIG is
+anabled)\n");

Also I am assuming that from signed initramfs, keys will be loaded in
appropriate keyrings and then keyring will be locked so that any 
tools from unsigned initramfs can not load additional keys.

Thanks
Vivek

Re: [RFC 2/2] initramfs with digital signature protection

[Kasatkin, Dmitry]

On Tue, Feb 5, 2013 at 8:34 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Tue, Feb 05, 2013 at 06:19:26PM +0000, Matthew Garrett wrote:
>> On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:
>>
>> > 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.
>>
>> What stops an attacker from simply removing the signed image from the
>> initramfs and running modified versions of the same tools from the
>> unsigned image?
>
> Looks like having signed initramfs image is mandatory otherwise system
> panics.
>
> +       if (sys_access(initramfs_img, 0))
> +               panic("signed initramfs image not found (INITRAMFS_SIG is
> +anabled)\n");
>
> Also I am assuming that from signed initramfs, keys will be loaded in
> appropriate keyrings and then keyring will be locked so that any
> tools from unsigned initramfs can not load additional keys.
>

Exactly like that.


> Thanks
> Vivek
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/2] initramfs with digital signature protection

[Vivek Goyal]

On Tue, Feb 05, 2013 at 11:55:09PM +0200, Kasatkin, Dmitry wrote:

[..]
> > Also I am assuming that from signed initramfs, keys will be loaded in
> > appropriate keyrings and then keyring will be locked so that any
> > tools from unsigned initramfs can not load additional keys.
> >
> 
> Exactly like that.

Dmitry,

[ Following up on this thread after a very long time ]

I was thinking about this point that keys can be loaded from signed
initramfs. But how is it better than embedding the keys in kernel the
way we do for module signing and lock down ima keyring before control
is passed to initramfs.

Reason being, that anyway a user can not put its own keys in signed
initramfs. Signed initramfs will be shipped by distribution. So then
it does not matter whether distribution's keys are embedded in the
kernel or are loaded from signed initramfs.

Thanks
Vivek

Re: [RFC 2/2] initramfs with digital signature protection

[Mimi Zohar]

On Fri, 2013-04-05 at 09:50 -0400, Vivek Goyal wrote:
> On Tue, Feb 05, 2013 at 11:55:09PM +0200, Kasatkin, Dmitry wrote:
> 
> [..]
> > > Also I am assuming that from signed initramfs, keys will be loaded in
> > > appropriate keyrings and then keyring will be locked so that any
> > > tools from unsigned initramfs can not load additional keys.
> > >
> > 
> > Exactly like that.
> 
> Dmitry,
> 
> [ Following up on this thread after a very long time ]
> 
> I was thinking about this point that keys can be loaded from signed
> initramfs. But how is it better than embedding the keys in kernel the
> way we do for module signing and lock down ima keyring before control
> is passed to initramfs.
> 
> Reason being, that anyway a user can not put its own keys in signed
> initramfs. Signed initramfs will be shipped by distribution. So then
> it does not matter whether distribution's keys are embedded in the
> kernel or are loaded from signed initramfs.

Although both the early initramfs and the kernel are signed, building
the keys into the kernel implies a static set of predefined public keys,
while the initramfs could load, in addition to the distro keys, keys
from the UEFI databases.  (Refer to James Bottomley's post on efivarfs.)
If distro's would sign such an early initramfs, it would allow users to
add their own keys in a safe and secure manner, without requiring them
to rebuild the kernel.

Mimi

Re: [RFC 2/2] initramfs with digital signature protection

[Vivek Goyal]

On Mon, Apr 08, 2013 at 03:43:49PM -0400, Mimi Zohar wrote:
> On Fri, 2013-04-05 at 09:50 -0400, Vivek Goyal wrote:
> > On Tue, Feb 05, 2013 at 11:55:09PM +0200, Kasatkin, Dmitry wrote:
> > 
> > [..]
> > > > Also I am assuming that from signed initramfs, keys will be loaded in
> > > > appropriate keyrings and then keyring will be locked so that any
> > > > tools from unsigned initramfs can not load additional keys.
> > > >
> > > 
> > > Exactly like that.
> > 
> > Dmitry,
> > 
> > [ Following up on this thread after a very long time ]
> > 
> > I was thinking about this point that keys can be loaded from signed
> > initramfs. But how is it better than embedding the keys in kernel the
> > way we do for module signing and lock down ima keyring before control
> > is passed to initramfs.
> > 
> > Reason being, that anyway a user can not put its own keys in signed
> > initramfs. Signed initramfs will be shipped by distribution. So then
> > it does not matter whether distribution's keys are embedded in the
> > kernel or are loaded from signed initramfs.
> 
> Although both the early initramfs and the kernel are signed, building
> the keys into the kernel implies a static set of predefined public keys,
> while the initramfs could load, in addition to the distro keys, keys
> from the UEFI databases.

Kernel already loads all the keys from UEFI database and MOK into module
keyring.

So that can be true for IMA too. A user can add its keys to UEFI database
or MOK and reboot the system and those keys should show up in kernel
keyring.

In addition any keys embedded in kernel at build time will be loaded too.

>  (Refer to James Bottomley's post on efivarfs.)

Are you referring to following link.

http://blog.hansenpartnership.com/efitools-1-4-with-linux-key-manipulation-utilities-released/

This one seems to be talking about tools for adding your own keys to
UEFI database if one has PK and KEK.

> If distro's would sign such an early initramfs, it would allow users to
> add their own keys in a safe and secure manner, without requiring them
> to rebuild the kernel.
> 

Sorry, I did not understand this part. Even if user adds its own keys
in UEFI database (using efivarfs filesystem), it does not require
rebuiling kernel. Over next reboot these keys should show up in kernel
keyring. So does not look like we will gain anything by creating a signed
initramfs.

Thanks
Vivek

Re: [RFC 2/2] initramfs with digital signature protection

[Josh Boyer]

On Mon, Apr 8, 2013 at 4:09 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Mon, Apr 08, 2013 at 03:43:49PM -0400, Mimi Zohar wrote:
>> On Fri, 2013-04-05 at 09:50 -0400, Vivek Goyal wrote:
>> > On Tue, Feb 05, 2013 at 11:55:09PM +0200, Kasatkin, Dmitry wrote:
>> >
>> > [..]
>> > > > Also I am assuming that from signed initramfs, keys will be loaded in
>> > > > appropriate keyrings and then keyring will be locked so that any
>> > > > tools from unsigned initramfs can not load additional keys.
>> > > >
>> > >
>> > > Exactly like that.
>> >
>> > Dmitry,
>> >
>> > [ Following up on this thread after a very long time ]
>> >
>> > I was thinking about this point that keys can be loaded from signed
>> > initramfs. But how is it better than embedding the keys in kernel the
>> > way we do for module signing and lock down ima keyring before control
>> > is passed to initramfs.
>> >
>> > Reason being, that anyway a user can not put its own keys in signed
>> > initramfs. Signed initramfs will be shipped by distribution. So then
>> > it does not matter whether distribution's keys are embedded in the
>> > kernel or are loaded from signed initramfs.
>>
>> Although both the early initramfs and the kernel are signed, building
>> the keys into the kernel implies a static set of predefined public keys,
>> while the initramfs could load, in addition to the distro keys, keys
>> from the UEFI databases.
>
> Kernel already loads all the keys from UEFI database and MOK into module
> keyring.

Small point of order: there are patches to allow the kernel to do this.
None of those patches are upstream.

josh

Re: [RFC 2/2] initramfs with digital signature protection

[Vivek Goyal]

On Mon, Apr 08, 2013 at 04:17:56PM -0400, Josh Boyer wrote:

[..]
> >> > I was thinking about this point that keys can be loaded from signed
> >> > initramfs. But how is it better than embedding the keys in kernel the
> >> > way we do for module signing and lock down ima keyring before control
> >> > is passed to initramfs.
> >> >
> >> > Reason being, that anyway a user can not put its own keys in signed
> >> > initramfs. Signed initramfs will be shipped by distribution. So then
> >> > it does not matter whether distribution's keys are embedded in the
> >> > kernel or are loaded from signed initramfs.
> >>
> >> Although both the early initramfs and the kernel are signed, building
> >> the keys into the kernel implies a static set of predefined public keys,
> >> while the initramfs could load, in addition to the distro keys, keys
> >> from the UEFI databases.
> >
> > Kernel already loads all the keys from UEFI database and MOK into module
> > keyring.
> 
> Small point of order: there are patches to allow the kernel to do this.
> None of those patches are upstream.

Ok, thanks Josh. We had been talking about copying all the UEFI keys
(including dbx) and MOK keys, so I assumed that patches already went in.

So assuming all that will go in kernel (as it is required for module
signature too), does not look like we will benefit from signed initramfs.

Thanks
Vivek

Re: [RFC 2/2] initramfs with digital signature protection

[Mimi Zohar]

On Tue, 2013-04-09 at 10:38 -0400, Vivek Goyal wrote:
> On Mon, Apr 08, 2013 at 04:17:56PM -0400, Josh Boyer wrote:
> 
> [..]
> > >> > I was thinking about this point that keys can be loaded from signed
> > >> > initramfs. But how is it better than embedding the keys in kernel the
> > >> > way we do for module signing and lock down ima keyring before control
> > >> > is passed to initramfs.
> > >> >
> > >> > Reason being, that anyway a user can not put its own keys in signed
> > >> > initramfs. Signed initramfs will be shipped by distribution. So then
> > >> > it does not matter whether distribution's keys are embedded in the
> > >> > kernel or are loaded from signed initramfs.
> > >>
> > >> Although both the early initramfs and the kernel are signed, building
> > >> the keys into the kernel implies a static set of predefined public keys,
> > >> while the initramfs could load, in addition to the distro keys, keys
> > >> from the UEFI databases.
> > >
> > > Kernel already loads all the keys from UEFI database and MOK into module
> > > keyring.
> > 
> > Small point of order: there are patches to allow the kernel to do this.
> > None of those patches are upstream.
> 
> Ok, thanks Josh. We had been talking about copying all the UEFI keys
> (including dbx) and MOK keys, so I assumed that patches already went in.
> 
> So assuming all that will go in kernel (as it is required for module
> signature too), does not look like we will benefit from signed initramfs.

The module keyring is a special case.  Loading these keys from the
kernel and, presumably, locking the keyring is probably fine.  In the
case of IMA, however, files will be signed by any number of package
owners.  If the _ima keyring is locked by the kernel, how would you add
these other keys?

thanks,

Mimi

Re: [RFC 2/2] initramfs with digital signature protection

[Vivek Goyal]

On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:

[..]
> The module keyring is a special case.  Loading these keys from the
> kernel and, presumably, locking the keyring is probably fine.  In the
> case of IMA, however, files will be signed by any number of package
> owners.  If the _ima keyring is locked by the kernel, how would you add
> these other keys?

Who are package owners here. IOW, in typical IMA setup, where are the keys
and when are these keys loaded in ima keyring?

If we trust root and keys can be loaded any time later, then signed
initramfs will not solve the problem either.

So this boils down to again not trusting root. So secureboot will not
trust root and IMA does. 

May be we need an additional IMA keyring which gets locked by kernel
(like module keyring). And during signing, we need to encode keyring
info in file signatuer. IMA will parse keyring info and try to verify
signature against that specified keyring.

/sbin/kexec signing can happen in such a way that we tell IMA to verify
against this locked keyring say, ima_kernel.

And in regular ima keyring, root can continue to load its own keys in
usual way even in secureboot mode.

Just that sys_kexec() will have to call into IMA to make sure that
/sbin/kexec's integrity was verified using keys in ima_kernel keyring 
and not using keys in _ima keyring.

IOW, apart from integrity results, we will have to store the keyring
info too in results which should be queryable by the client. And then
client can decide how to interpret integrity results.

Or we can just export the APIs from IMA (which don't do any caching) and
client can specify keyring to verify against as a parameter.

Thoughts?

Thanks
Vivek

Re: [RFC 2/2] initramfs with digital signature protection

[Mimi Zohar]

On Wed, 2013-04-10 at 15:42 -0400, Vivek Goyal wrote:
> On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:
> 
> [..]
> > The module keyring is a special case.  Loading these keys from the
> > kernel and, presumably, locking the keyring is probably fine.  In the
> > case of IMA, however, files will be signed by any number of package
> > owners.  If the _ima keyring is locked by the kernel, how would you add
> > these other keys?
> 
> Who are package owners here. IOW, in typical IMA setup, where are the keys
> and when are these keys loaded in ima keyring?

Suppose I install third party packages not signed by the distro, but by
the package owner (eg. google, rpmfusion, ...).  Not only does the
package signature need to be verified on installation, but the files
need to be installed with signatures.  For IMA to enforce file
integrity, the package owner's public key needs to be added to the _ima
keyring.

> If we trust root and keys can be loaded any time later, then signed
> initramfs will not solve the problem either.

Locking the keyring in the kernel will limit the set of permitted keys
to only those specified in UEFI db or builtin.  Locking the keyring in
the "early" initramfs, will allow the system owner, whose key is in the
UEFI db, to specify additional keys, such as those for third party
packages.  Not all public keys belong in the UEFI db.

Mimi

Re: [RFC 2/2] initramfs with digital signature protection

[Dmitry Kasatkin]

Hello,

(in plain text)

I respond to the original question of this thread.
signed initramfs allows not only to add keys to the keyrings but
perform other initialization,
which requires user-space.
Keys can be embedded into the kernel. This is fine.

Regards

- Dmitry


On Thu, Apr 11, 2013 at 12:05 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Wed, 2013-04-10 at 15:42 -0400, Vivek Goyal wrote:
>> On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:
>>
>> [..]
>> > The module keyring is a special case.  Loading these keys from the
>> > kernel and, presumably, locking the keyring is probably fine.  In the
>> > case of IMA, however, files will be signed by any number of package
>> > owners.  If the _ima keyring is locked by the kernel, how would you add
>> > these other keys?
>>
>> Who are package owners here. IOW, in typical IMA setup, where are the keys
>> and when are these keys loaded in ima keyring?
>
> Suppose I install third party packages not signed by the distro, but by
> the package owner (eg. google, rpmfusion, ...).  Not only does the
> package signature need to be verified on installation, but the files
> need to be installed with signatures.  For IMA to enforce file
> integrity, the package owner's public key needs to be added to the _ima
> keyring.
>
>> If we trust root and keys can be loaded any time later, then signed
>> initramfs will not solve the problem either.
>
> Locking the keyring in the kernel will limit the set of permitted keys
> to only those specified in UEFI db or builtin.  Locking the keyring in
> the "early" initramfs, will allow the system owner, whose key is in the
> UEFI db, to specify additional keys, such as those for third party
> packages.  Not all public keys belong in the UEFI db.
>
> Mimi
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/2] initramfs with digital signature protection

[Vivek Goyal]

On Wed, Apr 10, 2013 at 05:05:22PM -0400, Mimi Zohar wrote:
> On Wed, 2013-04-10 at 15:42 -0400, Vivek Goyal wrote:
> > On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:
> > 
> > [..]
> > > The module keyring is a special case.  Loading these keys from the
> > > kernel and, presumably, locking the keyring is probably fine.  In the
> > > case of IMA, however, files will be signed by any number of package
> > > owners.  If the _ima keyring is locked by the kernel, how would you add
> > > these other keys?
> > 
> > Who are package owners here. IOW, in typical IMA setup, where are the keys
> > and when are these keys loaded in ima keyring?
> 
> Suppose I install third party packages not signed by the distro, but by
> the package owner (eg. google, rpmfusion, ...).  Not only does the
> package signature need to be verified on installation, but the files
> need to be installed with signatures.  For IMA to enforce file
> integrity, the package owner's public key needs to be added to the _ima
> keyring.

Ok, got it. 

> 
> > If we trust root and keys can be loaded any time later, then signed
> > initramfs will not solve the problem either.
> 
> Locking the keyring in the kernel will limit the set of permitted keys
> to only those specified in UEFI db or builtin.  Locking the keyring in
> the "early" initramfs, will allow the system owner, whose key is in the
> UEFI db, to specify additional keys, such as those for third party
> packages.  Not all public keys belong in the UEFI db.

Ok, so third party public key you don't want to add in UEFI db. Instead
platform owner (whose key is in UEFI db) will regenerate initrafs and
sign it.

So above use case is primarily for user space files and verifying its
integrity and IMA keyring is used for that. secureboot does not require
IMA keyring to be locked as none of that code runs at ring0.

This locking requirement of IMA keyring is coming in only because we are
trying to also verify the integrity of a process who will load code which
runs at ring0.

So how do you like the idea of using another keyring (say system keyring)
for this purpose and what keyring to use integrity of a file can be
encoded in file signature.

This is something similar to INTEGRITY_KEYRING_MODULE keyring for modules.
(Though I don't see this code fully hooked up yet).

Or, given the fact that module signature and here /sbin/kexec verification
will make use of similar keys, we can create a system keyring, make module
code make use of that keyring. And IMA code can make use of that keyring
too if a file's digital signature indicates so.

Thanks
Vivek

Re: [RFC 2/2] initramfs with digital signature protection

[Mimi Zohar]

On Thu, 2013-04-11 at 10:52 -0400, Vivek Goyal wrote:
> On Wed, Apr 10, 2013 at 05:05:22PM -0400, Mimi Zohar wrote:
> > On Wed, 2013-04-10 at 15:42 -0400, Vivek Goyal wrote:
> > > On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:
> > > 
> > > [..]
> > > > The module keyring is a special case.  Loading these keys from the
> > > > kernel and, presumably, locking the keyring is probably fine.  In the
> > > > case of IMA, however, files will be signed by any number of package
> > > > owners.  If the _ima keyring is locked by the kernel, how would you add
> > > > these other keys?
> > > 
> > > Who are package owners here. IOW, in typical IMA setup, where are the keys
> > > and when are these keys loaded in ima keyring?
> > 
> > Suppose I install third party packages not signed by the distro, but by
> > the package owner (eg. google, rpmfusion, ...).  Not only does the
> > package signature need to be verified on installation, but the files
> > need to be installed with signatures.  For IMA to enforce file
> > integrity, the package owner's public key needs to be added to the _ima
> > keyring.
> 
> Ok, got it. 
> 
> > 
> > > If we trust root and keys can be loaded any time later, then signed
> > > initramfs will not solve the problem either.
> > 
> > Locking the keyring in the kernel will limit the set of permitted keys
> > to only those specified in UEFI db or builtin.  Locking the keyring in
> > the "early" initramfs, will allow the system owner, whose key is in the
> > UEFI db, to specify additional keys, such as those for third party
> > packages.  Not all public keys belong in the UEFI db.
> 
> Ok, so third party public key you don't want to add in UEFI db. Instead
> platform owner (whose key is in UEFI db) will regenerate initrafs and
> sign it.
> 
> So above use case is primarily for user space files and verifying its
> integrity and IMA keyring is used for that. secureboot does not require
> IMA keyring to be locked as none of that code runs at ring0.
> 
> This locking requirement of IMA keyring is coming in only because we are
> trying to also verify the integrity of a process who will load code which
> runs at ring0.
> 
> So how do you like the idea of using another keyring (say system keyring)
> for this purpose and what keyring to use integrity of a file can be
> encoded in file signature.
> 
> This is something similar to INTEGRITY_KEYRING_MODULE keyring for modules.
> (Though I don't see this code fully hooked up yet).
> 
> Or, given the fact that module signature and here /sbin/kexec verification
> will make use of similar keys, we can create a system keyring, make module
> code make use of that keyring. And IMA code can make use of that keyring
> too if a file's digital signature indicates so.

Sounds good to me!

thanks,

Mimi

Re: [RFC 2/2] initramfs with digital signature protection

[Vivek Goyal]

On Thu, Apr 11, 2013 at 11:06:55AM +0300, Dmitry Kasatkin wrote:
> Hello,
> 
> I respond to the original question of this thread.
> signed initramfs allows not only to add keys to the keyrings but perform
> other initialization,
> which requires user-space.
> Keys can be embedded into the kernel. This is fine.

What other initialization user space need to do where we can't trust
root (even in secureboot mode).

IOW, if keys can be embedded in kernel (or read from UEFI db and MOK db),
what other operation requires initramfs to be signed. It could very well
be unsigned initramfs like today.

Thanks
Vivek

Re: [RFC 2/2] initramfs with digital signature protection

[Dmitry Kasatkin]

On Thu, Apr 11, 2013 at 5:55 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Thu, Apr 11, 2013 at 11:06:55AM +0300, Dmitry Kasatkin wrote:
>> Hello,
>>
>> I respond to the original question of this thread.
>> signed initramfs allows not only to add keys to the keyrings but perform
>> other initialization,
>> which requires user-space.
>> Keys can be embedded into the kernel. This is fine.
>
> What other initialization user space need to do where we can't trust
> root (even in secureboot mode).
>
> IOW, if keys can be embedded in kernel (or read from UEFI db and MOK db),
> what other operation requires initramfs to be signed. It could very well
> be unsigned initramfs like today.
>

It looks like you do not hear me.
I said that any user space initialization can be done from signed user space.
For example IMA policy can be initialized.

I see that you see your particular case and in that case you do not
require that.
That is fine. That is your case....

 - Dmitry

> Thanks
> Vivek

Re: [RFC 2/2] initramfs with digital signature protection

[Vivek Goyal]

On Thu, Apr 11, 2013 at 09:42:54PM +0300, Dmitry Kasatkin wrote:

[..]
> > What other initialization user space need to do where we can't trust
> > root (even in secureboot mode).
> >
> > IOW, if keys can be embedded in kernel (or read from UEFI db and MOK db),
> > what other operation requires initramfs to be signed. It could very well
> > be unsigned initramfs like today.
> >
> 
> It looks like you do not hear me.
> I said that any user space initialization can be done from signed user space.
> For example IMA policy can be initialized.
> 

I am hearing you. Yes I heard you saying  "but perform other initialization,
which requires user-space". I am just trying to figure out more details.
You are assuming that a single line statement gives all the context and it
often might not be the case.

What makes it important that IMA policy is loaded from an signed initramfs
and not from unsigned one.

Also how would you make use of it without secureboot. Only secureboot will
allow to keep keys in firmware so that one can have a key in there and be
able to sign initramfs. 

In regular system, distributions do not ship pre-loaded keys so one can 
not sign initramfs. So only thing possible is that distributions enforce
some policy in signed initramfs and if distributions have to enforce a
policy they can do that in kernel itself and no need for signed initramfs.

Thanks
Vivek

Re: [RFC 2/2] initramfs with digital signature protection

[Mimi Zohar]

On Thu, 2013-04-11 at 17:13 -0400, Vivek Goyal wrote:
> On Thu, Apr 11, 2013 at 09:42:54PM +0300, Dmitry Kasatkin wrote:
> 
> [..]
> > > What other initialization user space need to do where we can't trust
> > > root (even in secureboot mode).
> > >
> > > IOW, if keys can be embedded in kernel (or read from UEFI db and MOK db),
> > > what other operation requires initramfs to be signed. It could very well
> > > be unsigned initramfs like today.
> > >
> > 
> > It looks like you do not hear me.
> > I said that any user space initialization can be done from signed user space.
> > For example IMA policy can be initialized.
> > 
> 
> I am hearing you. Yes I heard you saying  "but perform other initialization,
> which requires user-space". I am just trying to figure out more details.
> You are assuming that a single line statement gives all the context and it
> often might not be the case.
> 
> What makes it important that IMA policy is loaded from an signed initramfs
> and not from unsigned one.

> Also how would you make use of it without secureboot. Only secureboot will
> allow to keep keys in firmware so that one can have a key in there and be
> able to sign initramfs. 

You don't have a monopoly on secure boot.  We're all assuming a secure
boot environment.  The only question is what happens afterwards.  You're
interested in appraising a few particular files: kernel modules, kexec,
and the files kexec loads.  I'm interested in having all files in the
TCB measured and appraised.  Dmitry is interested in having all files
appraised.  The kernel needs to be able to support these and other
scenarios.

> In regular system, distributions do not ship pre-loaded keys so one can 
> not sign initramfs. So only thing possible is that distributions enforce
> some policy in signed initramfs and if distributions have to enforce a
> policy they can do that in kernel itself and no need for signed initramfs.

The difference is that one hard codes policy in the kernel, while the
other doesn't.  Having the policy in a signed initramfs, permits the
platform owner, for example, to change the policy.

Having said this, both Dmitry and I agreed with you that the UEFI keys
can be loaded from the kernel.  We disagree with you, that there is no
other purpose for a signed early initramfs.  Dmitry's example was
loading the IMA policy.  Another example is locking the _ima keyring.
Each scenario has its own requirements.

thanks,

Mimi

Re: [RFC 2/2] initramfs with digital signature protection

[Peter Jones]

On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:

> +static const char *secmnt = "/root";
> +static const char *initramfs_img = "/initramfs-sig.img";
> +
> +static int __init load_image(const char *from)
> +{
...
> +	err = sys_mount("tpmfs", (char *)secmnt, "tmpfs", MS_SILENT, NULL);
> +	if (err) {
> +		pr_err("sys_mount() = %d\n", err);
> +		goto out;
> +	}
> +
> +	sys_unshare(CLONE_FS | CLONE_FILES);
> +	sys_chdir(secmnt);
> +	sys_chroot(".");
> +	sys_setsid();
> +
> +	pr_info("unpack start\n");
> +	msg = unpack_to_rootfs(buf, offset);
...
> +}
> +
> +static int __init init_init(struct subprocess_info *info, struct cred *new)
> +{
> +	return load_image(initramfs_img);
> +}
> +
> +static void init_cleanup(struct subprocess_info *info)
> +{
> +	int err;
> +
> +	pr_info("cleanup\n");
> +
> +	err = sys_umount((char *)secmnt, MNT_DETACH);
> +	if (err)
> +		pr_err("unable to umount secmnt: %d\n", err);
> +}
> +
> +static int __init load_initramfs(void)
> +{
> +	static char *argv[] = { "pre-init", NULL, };
> +	extern char *envp_init[];
> +	int err;
> +
> +	/*
> +	 * In case that a resume from disk is carried out by linuxrc or one of
> +	 * its children, we need to tell the freezer not to wait for us.
> +	 */
> +	current->flags |= PF_FREEZER_SKIP;
> +
> +	err = call_usermodehelper_fns("/pre-init", argv, envp_init,
> +				      UMH_WAIT_PROC, init_init, init_cleanup,
> +				      NULL);
> +
> +	current->flags &= ~PF_FREEZER_SKIP;
> +
> +	pr_info("initramfs_sig /pre-init completed: %d\n", err);
> +
> +	return err;
> +}

So, there's another issue here - if you do want to run a fully-signed 
initramfs, and so there's nothing else in the container, you go through
this code and it mounts it.  In this case the wrapper initramfs which
includes the signed image is still in memory, and there's nothing e.g.
dracut can do about it.  Which means you've got two whole copies of the
initramfs in memory, and even if code later cleans up the one it sees,
you can't get rid of the other one.

(this would not be an issue without the wrapper.)

-- 
        Peter

Re: [RFC 2/2] initramfs with digital signature protection

[Kasatkin, Dmitry]

On Tue, Feb 5, 2013 at 10:36 PM, Peter Jones <pjones@redhat.com> wrote:
> On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:
>
>> +static const char *secmnt = "/root";
>> +static const char *initramfs_img = "/initramfs-sig.img";
>> +
>> +static int __init load_image(const char *from)
>> +{
> ...
>> +     err = sys_mount("tpmfs", (char *)secmnt, "tmpfs", MS_SILENT, NULL);
>> +     if (err) {
>> +             pr_err("sys_mount() = %d\n", err);
>> +             goto out;
>> +     }
>> +
>> +     sys_unshare(CLONE_FS | CLONE_FILES);
>> +     sys_chdir(secmnt);
>> +     sys_chroot(".");
>> +     sys_setsid();
>> +
>> +     pr_info("unpack start\n");
>> +     msg = unpack_to_rootfs(buf, offset);
> ...
>> +}
>> +
>> +static int __init init_init(struct subprocess_info *info, struct cred *new)
>> +{
>> +     return load_image(initramfs_img);
>> +}
>> +
>> +static void init_cleanup(struct subprocess_info *info)
>> +{
>> +     int err;
>> +
>> +     pr_info("cleanup\n");
>> +
>> +     err = sys_umount((char *)secmnt, MNT_DETACH);
>> +     if (err)
>> +             pr_err("unable to umount secmnt: %d\n", err);
>> +}
>> +
>> +static int __init load_initramfs(void)
>> +{
>> +     static char *argv[] = { "pre-init", NULL, };
>> +     extern char *envp_init[];
>> +     int err;
>> +
>> +     /*
>> +      * In case that a resume from disk is carried out by linuxrc or one of
>> +      * its children, we need to tell the freezer not to wait for us.
>> +      */
>> +     current->flags |= PF_FREEZER_SKIP;
>> +
>> +     err = call_usermodehelper_fns("/pre-init", argv, envp_init,
>> +                                   UMH_WAIT_PROC, init_init, init_cleanup,
>> +                                   NULL);
>> +
>> +     current->flags &= ~PF_FREEZER_SKIP;
>> +
>> +     pr_info("initramfs_sig /pre-init completed: %d\n", err);
>> +
>> +     return err;
>> +}
>
> So, there's another issue here - if you do want to run a fully-signed
> initramfs, and so there's nothing else in the container, you go through
> this code and it mounts it.  In this case the wrapper initramfs which
> includes the signed image is still in memory, and there's nothing e.g.
> dracut can do about it.  Which means you've got two whole copies of the
> initramfs in memory, and even if code later cleans up the one it sees,
> you can't get rid of the other one.
>
> (this would not be an issue without the wrapper.)
>

It should not be like that. Actually when pre-init exits, cleanup code
umount tmpfs,
which in turn cleanups the RAM.

Also ffter unpacking of signed image, it can be just removed.
In fact, IIRC, switch root cleans up ramfs.

I think everything is fine here...

Thanks,

Dmitry

> --
>         Peter

Re: [RFC 2/2] initramfs with digital signature protection

[H. Peter Anvin]

On 02/05/2013 02:09 PM, Kasatkin, Dmitry wrote:
>
> It should not be like that. Actually when pre-init exits, cleanup code
> umount tmpfs, which in turn cleanups the RAM.
>

It doesn't quite... the rootfs is permanent.  This is also only one 
usage mode: there are quite a few Linux systems running directly out of 
initramfs.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [RFC 2/2] initramfs with digital signature protection

[Kasatkin, Dmitry]

On Wed, Feb 6, 2013 at 7:04 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 02/05/2013 02:09 PM, Kasatkin, Dmitry wrote:
>>
>>
>> It should not be like that. Actually when pre-init exits, cleanup code
>> umount tmpfs, which in turn cleanups the RAM.
>>
>
> It doesn't quite... the rootfs is permanent.  This is also only one usage
> mode: there are quite a few Linux systems running directly out of initramfs.
>

rootfs is not permanent when it is ramfs. It is cleaned up on switch root.
It is easy to find out that it is empty by mounting : mount -t ramfs
rootfs /mnt/

In the case of running from normal storage, of course, there is
ridicules remove the content.

- Dmitry


>         -hpa
>
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
>

Re: [RFC 2/2] initramfs with digital signature protection

[H. Peter Anvin]

The cleanup is not a umount, it is actually a tree walk unlinking the contents.

"Kasatkin, Dmitry" <dmitry.kasatkin@intel.com> wrote:

>On Wed, Feb 6, 2013 at 7:04 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 02/05/2013 02:09 PM, Kasatkin, Dmitry wrote:
>>>
>>>
>>> It should not be like that. Actually when pre-init exits, cleanup
>code
>>> umount tmpfs, which in turn cleanups the RAM.
>>>
>>
>> It doesn't quite... the rootfs is permanent.  This is also only one
>usage
>> mode: there are quite a few Linux systems running directly out of
>initramfs.
>>
>
>rootfs is not permanent when it is ramfs. It is cleaned up on switch
>root.
>It is easy to find out that it is empty by mounting : mount -t ramfs
>rootfs /mnt/
>
>In the case of running from normal storage, of course, there is
>ridicules remove the content.
>
>- Dmitry
>
>
>>         -hpa
>>
>>
>> --
>> H. Peter Anvin, Intel Open Source Technology Center
>> I work for Intel.  I don't speak on their behalf.
>>

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [RFC 2/2] initramfs with digital signature protection

[Kasatkin, Dmitry]

On Wed, Feb 6, 2013 at 6:41 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> The cleanup is not a umount, it is actually a tree walk unlinking the contents.
>

Please see that umounting ramfs releases the memory.
There was no forced cleanup.
"cp" copied about 2GB of content.
After umounting we got 2GB back to free RAM...

kds@kds:~$ sudo mount -t ramfs testramfs /test
kds@kds:~$ sudo cp -r /usr/ /test
kds@kds:~$ du -sm /test
2154    /test
kds@kds:~$ free
                       total       used            free     shared
buffers     cached
Mem:       8058600    7855780     202820          0      24768    4819136
-/+ buffers/cache:    3011876    5046724
Swap:            0          0          0
kds@kds:~$ sudo umount /test
kds@kds:~$ free
                      total       used            free     shared
buffers     cached
Mem:       8058600    5644864    2413736          0      25268    2623956
-/+ buffers/cache:    2995640    5062960
Swap:            0          0          0

The same happens also with tmpfs.

- Dmitry

> "Kasatkin, Dmitry" <dmitry.kasatkin@intel.com> wrote:
>
>>On Wed, Feb 6, 2013 at 7:04 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 02/05/2013 02:09 PM, Kasatkin, Dmitry wrote:
>>>>
>>>>
>>>> It should not be like that. Actually when pre-init exits, cleanup
>>code
>>>> umount tmpfs, which in turn cleanups the RAM.
>>>>
>>>
>>> It doesn't quite... the rootfs is permanent.  This is also only one
>>usage
>>> mode: there are quite a few Linux systems running directly out of
>>initramfs.
>>>
>>
>>rootfs is not permanent when it is ramfs. It is cleaned up on switch
>>root.
>>It is easy to find out that it is empty by mounting : mount -t ramfs
>>rootfs /mnt/
>>
>>In the case of running from normal storage, of course, there is
>>ridicules remove the content.
>>
>>- Dmitry
>>
>>
>>>         -hpa
>>>
>>>
>>> --
>>> H. Peter Anvin, Intel Open Source Technology Center
>>> I work for Intel.  I don't speak on their behalf.
>>>
>
> --
> Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [RFC 2/2] initramfs with digital signature protection

[H. Peter Anvin]

Yes, but you can't umount rootfs.

"Kasatkin, Dmitry" <dmitry.kasatkin@intel.com> wrote:

>On Wed, Feb 6, 2013 at 6:41 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> The cleanup is not a umount, it is actually a tree walk unlinking the
>contents.
>>
>
>Please see that umounting ramfs releases the memory.
>There was no forced cleanup.
>"cp" copied about 2GB of content.
>After umounting we got 2GB back to free RAM...
>
>kds@kds:~$ sudo mount -t ramfs testramfs /test
>kds@kds:~$ sudo cp -r /usr/ /test
>kds@kds:~$ du -sm /test
>2154    /test
>kds@kds:~$ free
>                       total       used            free     shared
>buffers     cached
>Mem:       8058600    7855780     202820          0      24768   
>4819136
>-/+ buffers/cache:    3011876    5046724
>Swap:            0          0          0
>kds@kds:~$ sudo umount /test
>kds@kds:~$ free
>                      total       used            free     shared
>buffers     cached
>Mem:       8058600    5644864    2413736          0      25268   
>2623956
>-/+ buffers/cache:    2995640    5062960
>Swap:            0          0          0
>
>The same happens also with tmpfs.
>
>- Dmitry
>
>> "Kasatkin, Dmitry" <dmitry.kasatkin@intel.com> wrote:
>>
>>>On Wed, Feb 6, 2013 at 7:04 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>>> On 02/05/2013 02:09 PM, Kasatkin, Dmitry wrote:
>>>>>
>>>>>
>>>>> It should not be like that. Actually when pre-init exits, cleanup
>>>code
>>>>> umount tmpfs, which in turn cleanups the RAM.
>>>>>
>>>>
>>>> It doesn't quite... the rootfs is permanent.  This is also only one
>>>usage
>>>> mode: there are quite a few Linux systems running directly out of
>>>initramfs.
>>>>
>>>
>>>rootfs is not permanent when it is ramfs. It is cleaned up on switch
>>>root.
>>>It is easy to find out that it is empty by mounting : mount -t ramfs
>>>rootfs /mnt/
>>>
>>>In the case of running from normal storage, of course, there is
>>>ridicules remove the content.
>>>
>>>- Dmitry
>>>
>>>
>>>>         -hpa
>>>>
>>>>
>>>> --
>>>> H. Peter Anvin, Intel Open Source Technology Center
>>>> I work for Intel.  I don't speak on their behalf.
>>>>
>>
>> --
>> Sent from my mobile phone. Please excuse brevity and lack of
>formatting.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [RFC 2/2] initramfs with digital signature protection

[Kasatkin, Dmitry]

On Fri, Feb 8, 2013 at 5:49 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Yes, but you can't umount rootfs.

But that was not a rootfs, but tmpfs/ramfs mounted to /root folder.

>
> "Kasatkin, Dmitry" <dmitry.kasatkin@intel.com> wrote:
>
>>On Wed, Feb 6, 2013 at 6:41 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> The cleanup is not a umount, it is actually a tree walk unlinking the
>>contents.
>>>
>>
>>Please see that umounting ramfs releases the memory.
>>There was no forced cleanup.
>>"cp" copied about 2GB of content.
>>After umounting we got 2GB back to free RAM...
>>
>>kds@kds:~$ sudo mount -t ramfs testramfs /test
>>kds@kds:~$ sudo cp -r /usr/ /test
>>kds@kds:~$ du -sm /test
>>2154    /test
>>kds@kds:~$ free
>>                       total       used            free     shared
>>buffers     cached
>>Mem:       8058600    7855780     202820          0      24768
>>4819136
>>-/+ buffers/cache:    3011876    5046724
>>Swap:            0          0          0
>>kds@kds:~$ sudo umount /test
>>kds@kds:~$ free
>>                      total       used            free     shared
>>buffers     cached
>>Mem:       8058600    5644864    2413736          0      25268
>>2623956
>>-/+ buffers/cache:    2995640    5062960
>>Swap:            0          0          0
>>
>>The same happens also with tmpfs.
>>
>>- Dmitry
>>
>>> "Kasatkin, Dmitry" <dmitry.kasatkin@intel.com> wrote:
>>>
>>>>On Wed, Feb 6, 2013 at 7:04 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>>>> On 02/05/2013 02:09 PM, Kasatkin, Dmitry wrote:
>>>>>>
>>>>>>
>>>>>> It should not be like that. Actually when pre-init exits, cleanup
>>>>code
>>>>>> umount tmpfs, which in turn cleanups the RAM.
>>>>>>
>>>>>
>>>>> It doesn't quite... the rootfs is permanent.  This is also only one
>>>>usage
>>>>> mode: there are quite a few Linux systems running directly out of
>>>>initramfs.
>>>>>
>>>>
>>>>rootfs is not permanent when it is ramfs. It is cleaned up on switch
>>>>root.
>>>>It is easy to find out that it is empty by mounting : mount -t ramfs
>>>>rootfs /mnt/
>>>>
>>>>In the case of running from normal storage, of course, there is
>>>>ridicules remove the content.
>>>>
>>>>- Dmitry
>>>>
>>>>
>>>>>         -hpa
>>>>>
>>>>>
>>>>> --
>>>>> H. Peter Anvin, Intel Open Source Technology Center
>>>>> I work for Intel.  I don't speak on their behalf.
>>>>>
>>>
>>> --
>>> Sent from my mobile phone. Please excuse brevity and lack of
>>formatting.
>
> --
> Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [RFC 2/2] initramfs with digital signature protection

[H. Peter Anvin]

Yes, but I am talking about initramfs.

"Kasatkin, Dmitry" <dmitry.kasatkin@intel.com> wrote:

>On Fri, Feb 8, 2013 at 5:49 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> Yes, but you can't umount rootfs.
>
>But that was not a rootfs, but tmpfs/ramfs mounted to /root folder.
>
>>
>> "Kasatkin, Dmitry" <dmitry.kasatkin@intel.com> wrote:
>>
>>>On Wed, Feb 6, 2013 at 6:41 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>>> The cleanup is not a umount, it is actually a tree walk unlinking
>the
>>>contents.
>>>>
>>>
>>>Please see that umounting ramfs releases the memory.
>>>There was no forced cleanup.
>>>"cp" copied about 2GB of content.
>>>After umounting we got 2GB back to free RAM...
>>>
>>>kds@kds:~$ sudo mount -t ramfs testramfs /test
>>>kds@kds:~$ sudo cp -r /usr/ /test
>>>kds@kds:~$ du -sm /test
>>>2154    /test
>>>kds@kds:~$ free
>>>                       total       used            free     shared
>>>buffers     cached
>>>Mem:       8058600    7855780     202820          0      24768
>>>4819136
>>>-/+ buffers/cache:    3011876    5046724
>>>Swap:            0          0          0
>>>kds@kds:~$ sudo umount /test
>>>kds@kds:~$ free
>>>                      total       used            free     shared
>>>buffers     cached
>>>Mem:       8058600    5644864    2413736          0      25268
>>>2623956
>>>-/+ buffers/cache:    2995640    5062960
>>>Swap:            0          0          0
>>>
>>>The same happens also with tmpfs.
>>>
>>>- Dmitry
>>>
>>>> "Kasatkin, Dmitry" <dmitry.kasatkin@intel.com> wrote:
>>>>
>>>>>On Wed, Feb 6, 2013 at 7:04 AM, H. Peter Anvin <hpa@zytor.com>
>wrote:
>>>>>> On 02/05/2013 02:09 PM, Kasatkin, Dmitry wrote:
>>>>>>>
>>>>>>>
>>>>>>> It should not be like that. Actually when pre-init exits,
>cleanup
>>>>>code
>>>>>>> umount tmpfs, which in turn cleanups the RAM.
>>>>>>>
>>>>>>
>>>>>> It doesn't quite... the rootfs is permanent.  This is also only
>one
>>>>>usage
>>>>>> mode: there are quite a few Linux systems running directly out of
>>>>>initramfs.
>>>>>>
>>>>>
>>>>>rootfs is not permanent when it is ramfs. It is cleaned up on
>switch
>>>>>root.
>>>>>It is easy to find out that it is empty by mounting : mount -t
>ramfs
>>>>>rootfs /mnt/
>>>>>
>>>>>In the case of running from normal storage, of course, there is
>>>>>ridicules remove the content.
>>>>>
>>>>>- Dmitry
>>>>>
>>>>>
>>>>>>         -hpa
>>>>>>
>>>>>>
>>>>>> --
>>>>>> H. Peter Anvin, Intel Open Source Technology Center
>>>>>> I work for Intel.  I don't speak on their behalf.
>>>>>>
>>>>
>>>> --
>>>> Sent from my mobile phone. Please excuse brevity and lack of
>>>formatting.
>>
>> --
>> Sent from my mobile phone. Please excuse brevity and lack of
>formatting.

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

Re: [RFC 2/2] initramfs with digital signature protection

[Vivek Goyal]

On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:

[..]
> +static int __init load_initramfs(void)
> +{
> +	static char *argv[] = { "pre-init", NULL, };
> +	extern char *envp_init[];
> +	int err;
> +
> +	/*
> +	 * In case that a resume from disk is carried out by linuxrc or one of
> +	 * its children, we need to tell the freezer not to wait for us.
> +	 */
> +	current->flags |= PF_FREEZER_SKIP;
> +
> +	err = call_usermodehelper_fns("/pre-init", argv, envp_init,
> +				      UMH_WAIT_PROC, init_init, init_cleanup,
> +				      NULL);
> +
> +	current->flags &= ~PF_FREEZER_SKIP;
> +
> +	pr_info("initramfs_sig /pre-init completed: %d\n", err);
> +

Dmitry, 

How do we make sure that this is the first call to user mode helpers. I
see that we first unpacked unsigned initramfs. Then after a while we 
unpacked signed initramfs on /root and did a chroot. But now there is
a window before chroot, where kernel might call into /sbin/hotplug or
/sbin/modprobe from unsigned initramfs?

Specifically, I put some printk and I am seeing calls to /sbin/hotplug
before we even unpacked signed initramfs.

Thanks
Vivek

Re: [RFC 2/2] initramfs with digital signature protection

[Kasatkin, Dmitry]

On Thu, Feb 7, 2013 at 7:05 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Tue, Feb 05, 2013 at 02:34:50PM +0200, Dmitry Kasatkin wrote:
>
> [..]
>> +static int __init load_initramfs(void)
>> +{
>> +     static char *argv[] = { "pre-init", NULL, };
>> +     extern char *envp_init[];
>> +     int err;
>> +
>> +     /*
>> +      * In case that a resume from disk is carried out by linuxrc or one of
>> +      * its children, we need to tell the freezer not to wait for us.
>> +      */
>> +     current->flags |= PF_FREEZER_SKIP;
>> +
>> +     err = call_usermodehelper_fns("/pre-init", argv, envp_init,
>> +                                   UMH_WAIT_PROC, init_init, init_cleanup,
>> +                                   NULL);
>> +
>> +     current->flags &= ~PF_FREEZER_SKIP;
>> +
>> +     pr_info("initramfs_sig /pre-init completed: %d\n", err);
>> +
>
> Dmitry,
>
> How do we make sure that this is the first call to user mode helpers. I
> see that we first unpacked unsigned initramfs. Then after a while we
> unpacked signed initramfs on /root and did a chroot. But now there is
> a window before chroot, where kernel might call into /sbin/hotplug or
> /sbin/modprobe from unsigned initramfs?
>
> Specifically, I put some printk and I am seeing calls to /sbin/hotplug
> before we even unpacked signed initramfs.

If it really happens, then there something should be done to prevent it.
Can you please send me your patch with printks.
It would be interesting to analyze more what might happen.

Thanks,

Dmitry

>
> Thanks
> Vivek

Re: [RFC 2/2] initramfs with digital signature protection

[Kasatkin, Dmitry]

>>
>> Dmitry,
>>
>> How do we make sure that this is the first call to user mode helpers. I
>> see that we first unpacked unsigned initramfs. Then after a while we
>> unpacked signed initramfs on /root and did a chroot. But now there is
>> a window before chroot, where kernel might call into /sbin/hotplug or
>> /sbin/modprobe from unsigned initramfs?
>>
>> Specifically, I put some printk and I am seeing calls to /sbin/hotplug
>> before we even unpacked signed initramfs.
>

I did some experiments and made this  patch which prevents launching
of user mode helpers before pre-init from signed image is executed.

I do not know if this is the right way to do it, but at least it works for me.
The whole idea of these patches is to allow simple usage of signed image,
without the need to modify kernel parameters (0 block) and boot loaders....

--------------------------------------------------------------------------------------------------
commit a99eaa06ab142906da67800423425b7c5def0a3e
Author: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Date:   Fri Feb 8 15:05:22 2013 +0200

    initramfs_sig: prevent usermode helpers before signed image is executed

    This patch prevents execution of user mode helper before /pre-init
    is executed.

    Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>

diff --git a/include/linux/kmod.h b/include/linux/kmod.h
index 5398d58..8b6d2d5 100644
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -53,6 +53,8 @@ struct file;
 #define UMH_WAIT_PROC	2	/* wait for the process to complete */
 #define UMH_KILLABLE	4	/* wait for EXEC/PROC killable */

+#define UMH_FLAGS_SIG	0x01
+
 struct subprocess_info {
 	struct work_struct work;
 	struct completion *complete;
@@ -64,6 +66,7 @@ struct subprocess_info {
 	int (*init)(struct subprocess_info *info, struct cred *new);
 	void (*cleanup)(struct subprocess_info *info);
 	void *data;
+	unsigned flags;
 };

 extern int
@@ -71,6 +74,12 @@ call_usermodehelper_fns(char *path, char **argv,
char **envp, int wait,
 			int (*init)(struct subprocess_info *info, struct cred *new),
 			void (*cleanup)(struct subprocess_info *), void *data);

+extern int
+__call_usermodehelper_fns(char *path, char **argv, char **envp, int wait,
+			  int (*init)(struct subprocess_info *info, struct cred *new),
+			  void (*cleanup)(struct subprocess_info *),
+			  void *data, unsigned flags);
+
 static inline int
 call_usermodehelper(char *path, char **argv, char **envp, int wait)
 {
diff --git a/init/initramfs_sig.c b/init/initramfs_sig.c
index 3385414..7ab0604 100644
--- a/init/initramfs_sig.c
+++ b/init/initramfs_sig.c
@@ -146,9 +146,9 @@ static int __init load_initramfs(void)
 	 */
 	current->flags |= PF_FREEZER_SKIP;

-	err = call_usermodehelper_fns("/pre-init", argv, envp_init,
-				      UMH_WAIT_PROC, init_init, init_cleanup,
-				      NULL);
+	err = __call_usermodehelper_fns("/pre-init", argv, envp_init,
+				        UMH_WAIT_PROC, init_init, init_cleanup,
+				        NULL, UMH_FLAGS_SIG);

 	current->flags &= ~PF_FREEZER_SKIP;

@@ -167,5 +167,7 @@ int __init initramfs_sig_load(void)

 	pr_info("initramfs_sig finished\n");

+	usermodehelper_enable();
+
 	return 0;
 }
diff --git a/init/main.c b/init/main.c
index 43ef145..bbfa130 100644
--- a/init/main.c
+++ b/init/main.c
@@ -784,7 +784,9 @@ static void __init do_basic_setup(void)
 	driver_init();
 	init_irq_proc();
 	do_ctors();
+#ifndef CONFIG_INITRAMFS_SIG
 	usermodehelper_enable();
+#endif
 	do_initcalls();
 }

diff --git a/kernel/kmod.c b/kernel/kmod.c
index 0023a87..e4b9117 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
@@ -564,10 +564,12 @@ int call_usermodehelper_exec(struct
subprocess_info *sub_info, int wait)
 	if (sub_info->path[0] == '\0')
 		goto out;

-	if (!khelper_wq || usermodehelper_disabled) {
+	if (!khelper_wq || (usermodehelper_disabled &&
+		    !(sub_info->flags & UMH_FLAGS_SIG))) {
 		retval = -EBUSY;
 		goto out;
 	}
+	pr_info("initr: %s: %s\n", __func__, sub_info->path);
 	/*
 	 * Worker thread must not wait for khelper thread at below
 	 * wait_for_completion() if the thread was created with CLONE_VFORK
@@ -613,10 +615,10 @@ unlock:
  * check the call_usermodehelper_fns() return value: if it is -ENOMEM, perform
  * the necessaary cleanup within the caller.
  */
-int call_usermodehelper_fns(
+int __call_usermodehelper_fns(
 	char *path, char **argv, char **envp, int wait,
 	int (*init)(struct subprocess_info *info, struct cred *new),
-	void (*cleanup)(struct subprocess_info *), void *data)
+	void (*cleanup)(struct subprocess_info *), void *data, unsigned flags)
 {
 	struct subprocess_info *info;
 	gfp_t gfp_mask = (wait == UMH_NO_WAIT) ? GFP_ATOMIC : GFP_KERNEL;
@@ -628,8 +630,18 @@ int call_usermodehelper_fns(

 	call_usermodehelper_setfns(info, init, cleanup, data);

+	info->flags = flags;
+
 	return call_usermodehelper_exec(info, wait);
 }
+
+int call_usermodehelper_fns(
+	char *path, char **argv, char **envp, int wait,
+	int (*init)(struct subprocess_info *info, struct cred *new),
+	void (*cleanup)(struct subprocess_info *), void *data)
+{
+	return __call_usermodehelper_fns(path, argv, envp, wait, init,
cleanup, data, 0);
+}
 EXPORT_SYMBOL(call_usermodehelper_fns);

 static int proc_cap_handler(struct ctl_table *table, int write,

Re: [RFC 2/2] initramfs with digital signature protection

[Vivek Goyal]

On Fri, Feb 08, 2013 at 03:27:30PM +0200, Kasatkin, Dmitry wrote:
> >>
> >> Dmitry,
> >>
> >> How do we make sure that this is the first call to user mode helpers. I
> >> see that we first unpacked unsigned initramfs. Then after a while we
> >> unpacked signed initramfs on /root and did a chroot. But now there is
> >> a window before chroot, where kernel might call into /sbin/hotplug or
> >> /sbin/modprobe from unsigned initramfs?
> >>
> >> Specifically, I put some printk and I am seeing calls to /sbin/hotplug
> >> before we even unpacked signed initramfs.
> >
> 
> I did some experiments and made this  patch which prevents launching
> of user mode helpers before pre-init from signed image is executed.
> 
> I do not know if this is the right way to do it, but at least it works for me.
> The whole idea of these patches is to allow simple usage of signed image,
> without the need to modify kernel parameters (0 block) and boot loaders....
> 
> --------------------------------------------------------------------------------------------------
> commit a99eaa06ab142906da67800423425b7c5def0a3e
> Author: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
> Date:   Fri Feb 8 15:05:22 2013 +0200
> 
>     initramfs_sig: prevent usermode helpers before signed image is executed
> 
>     This patch prevents execution of user mode helper before /pre-init
>     is executed.
> 
>     Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>

Yep. This seems to have blocked the calls going out to user space and
returns with -EBUSY

Thanks
Vivek