[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1363803158.2553.33.camel@x230.sbx07502.somerma.wayport.net>
Date: Wed, 20 Mar 2013 18:12:38 +0000
From: Matthew Garrett <matthew.garrett@...ula.com>
To: Mimi Zohar <zohar@...ux.vnet.ibm.com>
CC: James Morris <jmorris@...ei.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL
On Wed, 2013-03-20 at 14:01 -0400, Mimi Zohar wrote:
> Sorry, I'm not sure to which work you're referring. If you're referring
> to Dmitry's "initramfs with digital signature protection" patches, then
> we're speaking about enforcing integrity, not MAC security.
Well, in the absence of hardcoded in-kernel policy, there needs to be
some mechanism for ensuring the integrity of a policy. Shipping a signed
policy initramfs fragment and having any Secure Boot bootloaders pass a
flag in bootparams indicating that the kernel should panic if that
fragment isn't present would seem to be the easiest way of doing that.
Or have I misunderstood the question?
--
Matthew Garrett | mjg59@...f.ucam.org
Powered by blists - more mailing lists