linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
	"Kasatkin, Dmitry" <dmitry.kasatkin@intel.com>,
	dhowells@redhat.com, jmorris@namei.org,
	linux-security-module@vger.kernel.org,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 1/1] ima: digital signature verification using asymmetric keys
Date: Wed, 30 Jan 2013 06:32:05 +0000	[thread overview]
Message-ID: <20130130063205.GA15032@srcf.ucam.org> (raw)
In-Reply-To: <20130129165853.GC21930@redhat.com>

On Tue, Jan 29, 2013 at 11:58:53AM -0500, Vivek Goyal wrote:
> On Mon, Jan 28, 2013 at 08:48:55PM -0500, Mimi Zohar wrote:
> > The assumption has always been that the initramfs would be measured, for
> > trusted boot, and appraised, for secure boot, before being executed.
> 
> Hi Mimi,
> 
> Ok. So for trusted boot, if initramfs is changed it will be detected. For
> secureboot, atleast right now initramfs is not signed and appraised. But
> I guess it could be added. 
> 
> But initramfs is generated by installer and installer does not have
> private keys to sign it. So distributions could not sign initramfs.

Right, there's a whole range of problems here. The first is that the 
initramfs has to contain the full set of drivers required to boot a 
given piece of hardware, and the precise set required varies between 
machines. Building a truly generic initramfs would result in 
significantly larger images.

There's also an existing expectation that it be possible to break into 
initramfs execution for debugging purposes. Even ignoring that, most 
initramfs implementations aren't expected to be hardened against a user 
inserting shell control characters into the kernel command line. It 
would require significant engineering work to ensure that there's no way 
for an attacker to cause code execution before the key store has been 
locked.

Shipping prebuilt initramfses is also difficult from a release 
engineering perspective. You'd need to keep track of the software 
versions that were included in the initramfs and ensure that the 
initramfs is rebuilt if any of those pieces of software are updated 
between the initramfs being generated and the software being shipped. 
Version skew could cause subtle bugs and also makes license compliance 
difficult.

Finally, portions of the userspace in initramfs may be under licenses 
that require it to be possible for the end user to replace components. 
This isn't a problem as long as the keys in MOK can be used.

There's additional small problems, like the initramfs containing the 
bootsplash theme and users expecting to be able to change that without 
having to generate crypto keys, but that's probably not a showstopper. 
But realistically, the first three problems make it unlikely that most 
distributions will be willing to depend on or ship pre-built initramfs 
images.

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

  reply	other threads:[~2013-01-30  6:32 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-15 10:34 [RFC 0/1] ima/evm: signature verification support using asymmetric keys Dmitry Kasatkin
2013-01-15 10:34 ` [RFC 1/1] ima: digital signature verification " Dmitry Kasatkin
2013-01-22 22:53   ` Mimi Zohar
2013-01-23  9:03     ` Kasatkin, Dmitry
2013-01-25 21:01       ` Vivek Goyal
2013-01-28 14:54         ` Kasatkin, Dmitry
2013-01-28 15:15           ` Vivek Goyal
2013-01-28 15:20             ` Kasatkin, Dmitry
2013-01-28 18:52               ` Vivek Goyal
2013-01-28 19:51                 ` Mimi Zohar
2013-01-28 20:13                   ` Vivek Goyal
2013-01-29  0:14                     ` Mimi Zohar
2013-01-29 16:30                       ` Vivek Goyal
2013-01-29  8:53                     ` Kasatkin, Dmitry
2013-01-29  8:48                 ` Kasatkin, Dmitry
2013-01-29 18:39                   ` Vivek Goyal
2013-01-28 18:56               ` Vivek Goyal
2013-01-28 20:15                 ` Mimi Zohar
2013-01-28 20:22                   ` Vivek Goyal
2013-01-29  1:48                     ` Mimi Zohar
2013-01-29 16:58                       ` Vivek Goyal
2013-01-30  6:32                         ` Matthew Garrett [this message]
2013-01-30 22:22                           ` Mimi Zohar
2013-01-29 18:20                       ` Vivek Goyal
2013-01-29 20:01                         ` Mimi Zohar
2013-01-29 20:10                           ` Vivek Goyal
2013-01-29 22:26                             ` Mimi Zohar
2013-01-16 19:45 ` [RFC 0/1] ima/evm: signature verification support " Mimi Zohar
2013-01-17 17:52 ` [RFC 1/1] ima: digital signature verification " David Howells
2013-01-17 18:00   ` Kasatkin, Dmitry
2013-01-17 18:03 ` [RFC 0/1] ima/evm: signature verification support " David Howells
2013-01-18 15:16   ` Mimi Zohar

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=20130130063205.GA15032@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@intel.com \
    --cc=jmorris@namei.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    --cc=zohar@linux.vnet.ibm.com \
    /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;
as well as URLs for NNTP newsgroup(s).