From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@intel.com>,
kexec@lists.infradead.org,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
horms@verge.net.au, "Eric W. Biederman" <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Matthew Garrett <mjg@redhat.com>, Dave Young <dyoung@redhat.com>,
Khalid Aziz <khalid@gonehiking.org>
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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
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: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-18 3:10 [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting Dave Young
2012-10-18 14:56 ` Khalid Aziz
2012-10-18 19:11 ` Vivek Goyal
2012-10-18 19:22 ` Khalid Aziz
2012-10-18 19:38 ` [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting) Vivek Goyal
2012-10-18 19:55 ` Matthew Garrett
2012-10-18 22:25 ` Eric W. Biederman
2012-10-19 2:06 ` Vivek Goyal
2012-10-19 3:36 ` Eric W. Biederman
2012-10-19 14:31 ` Vivek Goyal
2012-10-22 20:43 ` Vivek Goyal
2012-10-22 21:11 ` Eric W. Biederman
2012-10-23 2:04 ` Simon Horman
2012-10-23 13:24 ` Vivek Goyal
2012-10-23 16:26 ` [RFC] Kdump with signed images Eric W. Biederman
2012-10-23 17:39 ` Vivek Goyal
2012-10-23 19:11 ` Maxim Uvarov
2012-10-23 19:16 ` Vivek Goyal
2012-10-22 21:07 ` [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting) Eric W. Biederman
2012-10-23 13:18 ` Vivek Goyal
2012-10-23 14:59 ` Vivek Goyal
2012-10-23 15:41 ` Matthew Garrett
2012-10-23 16:44 ` [RFC] Kdump with signed images Eric W. Biederman
2012-10-23 16:52 ` Matthew Garrett
2012-10-24 17:19 ` Vivek Goyal
2012-10-24 17:19 ` Vivek Goyal
2012-10-25 5:43 ` Mimi Zohar
2012-10-25 5:43 ` Mimi Zohar
2012-10-25 6:44 ` Kees Cook
2012-10-25 6:44 ` Kees Cook
2012-10-25 7:01 ` Mimi Zohar
2012-10-25 7:01 ` Mimi Zohar
2012-10-25 13:54 ` Vivek Goyal
2012-10-25 13:54 ` Vivek Goyal
2012-10-25 19:06 ` Mimi Zohar
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
2012-10-25 15:39 ` Vivek Goyal
2012-10-23 16:19 ` Kdump with signed images Eric W. Biederman
2012-10-23 16:31 ` Matthew Garrett
2012-10-23 17:03 ` Eric W. Biederman
2012-10-23 17:09 ` Matthew Garrett
2012-10-24 17:36 ` Vivek Goyal
2012-10-24 17:36 ` Vivek Goyal
2012-10-25 6:10 ` Mimi Zohar [this message]
2012-10-25 6:10 ` Mimi Zohar
2012-10-25 14:10 ` Vivek Goyal
2012-10-25 14:10 ` Vivek Goyal
2012-10-25 18:40 ` Mimi Zohar
2012-10-25 18:40 ` Mimi Zohar
2012-10-25 18:55 ` Vivek Goyal
2012-10-25 18:55 ` Vivek Goyal
2012-10-26 1:15 ` Mimi Zohar
2012-10-26 1:15 ` Mimi Zohar
2012-10-26 2:39 ` Matthew Garrett
2012-10-26 2:39 ` Matthew Garrett
2012-10-26 3:30 ` Eric W. Biederman
2012-10-26 3:30 ` Eric W. Biederman
2012-10-26 17:06 ` Vivek Goyal
2012-10-26 17:06 ` Vivek Goyal
2012-10-26 18:37 ` Mimi Zohar
2012-10-26 18:37 ` Mimi Zohar
2012-11-01 13:10 ` Vivek Goyal
2012-11-01 13:10 ` Vivek Goyal
2012-11-01 13:53 ` Vivek Goyal
2012-11-01 13:53 ` Vivek Goyal
2012-11-01 14:29 ` Mimi Zohar
2012-11-01 14:29 ` Mimi Zohar
2012-11-01 14:43 ` Vivek Goyal
2012-11-01 14:43 ` Vivek Goyal
2012-11-01 14:52 ` Matthew Garrett
2012-11-01 14:52 ` Matthew Garrett
2012-11-02 13:23 ` Vivek Goyal
2012-11-02 13:23 ` Vivek Goyal
2012-11-02 14:29 ` Balbir Singh
2012-11-02 14:29 ` Balbir Singh
2012-11-02 14:36 ` Vivek Goyal
2012-11-02 14:36 ` Vivek Goyal
2012-11-03 3:02 ` Balbir Singh
2012-11-03 3:02 ` Balbir Singh
2012-11-02 21:34 ` H. Peter Anvin
2012-11-02 21:34 ` H. Peter Anvin
2012-11-02 21:32 ` Eric W. Biederman
2012-11-02 21:32 ` Eric W. Biederman
2012-11-05 18:03 ` Vivek Goyal
2012-11-05 18:03 ` Vivek Goyal
2012-11-05 19:44 ` Eric W. Biederman
2012-11-05 19:44 ` Eric W. Biederman
2012-11-05 20:42 ` Vivek Goyal
2012-11-05 20:42 ` Vivek Goyal
2012-11-05 23:01 ` H. Peter Anvin
2012-11-05 23:01 ` H. Peter Anvin
2012-11-06 19:34 ` Vivek Goyal
2012-11-06 19:34 ` Vivek Goyal
2012-11-06 23:51 ` Eric W. Biederman
2012-11-06 23:51 ` Eric W. Biederman
2012-11-08 19:40 ` Vivek Goyal
2012-11-08 19:40 ` Vivek Goyal
2012-11-08 19:45 ` Vivek Goyal
2012-11-08 19:45 ` Vivek Goyal
2012-11-08 21:03 ` Eric W. Biederman
2012-11-08 21:03 ` Eric W. Biederman
2012-11-09 14:39 ` Vivek Goyal
2012-11-09 14:39 ` Vivek Goyal
2012-11-15 5:09 ` Eric W. Biederman
2012-11-15 5:09 ` Eric W. Biederman
2012-11-15 12:56 ` Mimi Zohar
2012-11-15 12:56 ` Mimi Zohar
2012-11-08 20:46 ` Mimi Zohar
2012-11-08 20:46 ` Mimi Zohar
2012-11-01 14:51 ` Vivek Goyal
2012-11-01 14:51 ` Vivek Goyal
2012-11-01 14:57 ` Matthew Garrett
2012-11-01 14:57 ` Matthew Garrett
2012-11-01 15:10 ` Khalid Aziz
2012-11-01 15:10 ` Khalid Aziz
2012-11-01 16:23 ` Matthew Garrett
2012-11-01 16:23 ` Matthew Garrett
2012-11-02 16:57 ` Khalid Aziz
2012-11-02 16:57 ` Khalid Aziz
2012-10-26 17:59 ` Mimi Zohar
2012-10-26 17:59 ` Mimi Zohar
2012-10-26 18:19 ` Matthew Garrett
2012-10-26 18:19 ` Matthew Garrett
2012-10-26 18:25 ` Mimi Zohar
2012-10-26 18:25 ` Mimi Zohar
2012-10-23 15:51 ` [RFC] Kdump with UEFI secure boot (Re: [PATCH v2] kdump: pass acpi_rsdp= to 2nd kernel for efi booting) Eric W. Biederman
2012-10-23 17:18 ` Vivek Goyal
2012-10-19 17:53 ` Vivek Goyal
2012-10-22 21:15 ` Eric W. Biederman
2012-11-02 21:36 ` H. Peter Anvin
2012-11-05 18:11 ` Vivek Goyal
2012-11-05 19:54 ` Eric W. Biederman
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.