[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1363814289.2553.41.camel@x230.sbx07502.somerma.wayport.net>
Date: Wed, 20 Mar 2013 21:18:10 +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>,
"Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL
On Wed, 2013-03-20 at 17:11 -0400, Mimi Zohar wrote:
> On Wed, 2013-03-20 at 20:37 +0000, Matthew Garrett wrote:
> > Right, that'd be the rough idea. Any further runtime policy updates
> > would presumably need to be signed with a trusted key.
>
> I'm really sorry to belabor this point, but can kexec rely on an LSM
> label to identify a specific file, out of all the files being executed,
> in a secure boot environment? The SELinux integrity rule for kexec
> would then look something like,
>
> appraise func=BPRM_CHECK obj_type=kdump_exec_t appraise_type=imasig
It would certainly be possible to configure a system such that this was
true (assuming support for signed initramfs and restricted policy
loading), and anyone wanting to ensure that kexec only loaded trusted
binaries would have to ensure that their system was appropriately
configured. Having some mechanism to then give the kexec binary
CAP_MODIFY_KERNEL would avoid needing an extra kexec entry point.
--
Matthew Garrett | mjg59@...f.ucam.org
Powered by blists - more mailing lists