On Tue, Feb 5, 2013 at 8:03 PM, Peter Jones <pjo...@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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
