From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Khalid Aziz <khalid@gonehiking.org>,
kexec@lists.infradead.org, horms@verge.net.au,
Dave Young <dyoung@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Matthew Garrett <mjg@redhat.com>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Subject: Re: Kdump with signed images
Date: Thu, 25 Oct 2012 02:10:01 -0400 [thread overview]
Message-ID: <1351145401.18115.78.camel@falcor> (raw)
In-Reply-To: <20121024173651.GE1821@redhat.com>
On Wed, 2012-10-24 at 13:36 -0400, Vivek Goyal wrote:
> On Tue, Oct 23, 2012 at 09:19:27AM -0700, Eric W. Biederman wrote:
> > Vivek Goyal <vgoyal@redhat.com> writes:
> >
> > > On Tue, Oct 23, 2012 at 09:18:54AM -0400, Vivek Goyal wrote:
> > >
> > > [..]
> > >> > >> There are 3 options for trusting /sbin/kexec. There are IMA and EMA,
> > >> > >> and it is conceivable to have ELF note sections with signatures for
> > >> > >> executables.
> > >> > >
> > >> > > Can you please tell more about what is EMA and IMA. I did quick google
> > >> > > and could not find much.
> > >> >
> > >> > That should have been EVM and IMA. Look under security/integrity/. I
> > >> > don't know much about them but they appear to be security modules with a
> > >> > focus on verifying checksum or perhaps encrypted hashes of executables
> > >> > are consistent.
> > >>
> > >> I will do some quick search there and I see if I can understand something.
> > >>
> > >
> > > Ok, I quickly went through following paper.
> > >
> > > http://mirror.transact.net.au/sourceforge/l/project/li/linux-ima/linux-ima/Integrity_overview.pdf
> > >
> > > So it looks like that IMA can store the hashes of files and at execute
> > > time ensure those hashes are unchanged to protect against the possibility
> > > of modification of files.
IMA-appraisal originally was hashed based, but Dmitry Kasatkin added
digital signature support. Both have been upstreamed.
> > > But what about creation of a new program which can call kexec_load()
> > > and execute an unsigned kernel. Doesn't look like that will be
> > > prevented using IMA.
Assuming the IMA policy syntax is updated to require 'security.ima' to
contain a digital signature, then it is only a question of protecting
the _ima and _evm keyrings. (Dmitry has such a patch waiting to be
reviewed.) So the new program would have to be vetted by someone
trusted.
> > > Whole idea behind UEFI secure boot seems to be that all signing happens
> > > outside the running system and now only signed code can run with higher
> > > priviliges.
> >
> > No. UEFI secure boot has absolutely nothing todo with this.
> >
> > UEFI secure boot is about not being able to hijack the code EFI runs
> > directly. Full stop.
> >
> > Some people would like to implment a security policy that says
> > you can't boot an untrusted version of windows from linux if you have
> > booted with UEFI secure boot, so they don't get their bootloader
> > signatures revoked by microsoft.
> >
> > A security model relying on Microsoft's key is totally uniteresting to
> > me. Either signing at the UEFI level is of no use or Microsofts key
> > will fall again to the combined assult of every cracker and every
> > governmental dirty cyber ops division attacking it. Not to mention that
> > Microsoft has little incentive to keep linux booting.
> >
> > I think it is reasonable to be able to support a policy where we can't
> > boot unsigned versions of Microsoft windows. However beyond being able
> > to exclude booting windows being one criteria for our policy mechanism
> > please don't even start to justify things with that ridiculous security
> > policy even indirectly.
> >
> > > IMA seems to be only protecting against only making sure
> > > existing binaries are not modifed but it does not seem to prevent against
> > > installation of new binaries and these binaries take advantage of kexec
> > > system call to load an unsigned kernel.
The IMA/IMA-appraisal policy dictates what needs to be appraised. The
default ima-appraisal policy appraises all files owned by root.
> > I believe you can combine IMA with EVM signed security attributes where
> > the EVM signing key is offline, and the verification key is in the
> > kernel.
> >
> > The combination of IMA and EVM gets very close to being able to sign
> > executables offline and be able to update them.
>
> [ Again CCing lkml and IMA/EVM folks ]
>
> After little reading, my understanding is EVM also does not support
> offline signing.
>
> http://sourceforge.net/apps/mediawiki/linux-ima/index.php?title=Main_Page
>
> Given the fact EVM protects IMA data (security.ima), which is generated
> inline, I am not sure how EVM can sign images offline.
>
> I might have misunderstood things, please correct me if that's not the
> case.
>
> Thanks
> Vivek
>
IMA-appraisal verifies the integrity of file data, while EVM verifies
the integrity of the file metadata, such as LSM and IMA-appraisal
labels. Both 'security.ima' and 'security.evm' can contain digital
signatures.
thanks,
Mimi
next prev parent reply other threads:[~2012-10-25 6:12 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1350588121.30243.7.camel@rhapsody>
[not found] ` <20121018193831.GD18147@redhat.com>
[not found] ` <874nlrv2ni.fsf@xmission.com>
[not found] ` <20121019020630.GA27052@redhat.com>
[not found] ` <877gqnnnf0.fsf@xmission.com>
[not found] ` <20121019143112.GB27052@redhat.com>
[not found] ` <871ugqb4gj.fsf@xmission.com>
[not found] ` <20121023131854.GA16496@redhat.com>
[not found] ` <20121023145920.GD16496@redhat.com>
[not found] ` <87fw552mb4.fsf_-_@xmission.com>
2012-10-24 17:36 ` Kdump with signed images Vivek Goyal
2012-10-25 6:10 ` Mimi Zohar [this message]
2012-10-25 14:10 ` Vivek Goyal
2012-10-25 18:40 ` Mimi Zohar
2012-10-25 18:55 ` Vivek Goyal
2012-10-26 1:15 ` Mimi Zohar
2012-10-26 2:39 ` Matthew Garrett
2012-10-26 3:30 ` Eric W. Biederman
2012-10-26 17:06 ` Vivek Goyal
2012-10-26 18:37 ` Mimi Zohar
2012-11-01 13:10 ` Vivek Goyal
2012-11-01 13:53 ` Vivek Goyal
2012-11-01 14:29 ` Mimi Zohar
2012-11-01 14:43 ` Vivek Goyal
2012-11-01 14:52 ` Matthew Garrett
2012-11-02 13:23 ` Vivek Goyal
2012-11-02 14:29 ` Balbir Singh
2012-11-02 14:36 ` Vivek Goyal
2012-11-03 3:02 ` Balbir Singh
2012-11-02 21:34 ` H. Peter Anvin
2012-11-02 21:32 ` Eric W. Biederman
2012-11-05 18:03 ` Vivek Goyal
2012-11-05 19:44 ` Eric W. Biederman
2012-11-05 20:42 ` Vivek Goyal
2012-11-05 23:01 ` H. Peter Anvin
2012-11-06 19:34 ` Vivek Goyal
2012-11-06 23:51 ` Eric W. Biederman
2012-11-08 19:40 ` Vivek Goyal
2012-11-08 19:45 ` Vivek Goyal
2012-11-08 21:03 ` Eric W. Biederman
2012-11-09 14:39 ` Vivek Goyal
2012-11-15 5:09 ` Eric W. Biederman
2012-11-15 12:56 ` Mimi Zohar
2012-11-08 20:46 ` Mimi Zohar
2012-11-01 14:51 ` Vivek Goyal
2012-11-01 14:57 ` Matthew Garrett
2012-11-01 15:10 ` Khalid Aziz
2012-11-01 16:23 ` Matthew Garrett
2012-11-02 16:57 ` Khalid Aziz
2012-10-26 17:59 ` Mimi Zohar
2012-10-26 18:19 ` Matthew Garrett
2012-10-26 18:25 ` Mimi Zohar
[not found] ` <20121023154123.GA30730@srcf.ucam.org>
[not found] ` <87d309xhmc.fsf_-_@xmission.com>
2012-10-24 17:19 ` [RFC] " Vivek Goyal
2012-10-25 5:43 ` Mimi Zohar
2012-10-25 6:44 ` Kees Cook
2012-10-25 7:01 ` Mimi Zohar
2012-10-25 13:54 ` Vivek Goyal
2012-10-25 19:06 ` Mimi Zohar
2012-10-25 15:39 ` [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting) Vivek Goyal
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=1351145401.18115.78.camel@falcor \
--to=zohar@linux.vnet.ibm.com \
--cc=dmitry.kasatkin@intel.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.org \
--cc=khalid@gonehiking.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=vgoyal@redhat.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).