lkml.org 
[lkml]   [2013]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary
From
Date
On Wed, 2013-01-16 at 09:48 -0500, Vivek Goyal wrote:
> On Wed, Jan 16, 2013 at 09:00:59AM -0500, Mimi Zohar wrote:
> > On Tue, 2013-01-15 at 23:10 -0800, Eric W. Biederman wrote:
> > > Mimi Zohar <zohar@linux.vnet.ibm.com> writes:
> > >
> > > > Please remind me why you can't use IMA-appraisal, which was upstreamed
> > > > in Linux 3.7? Why another method is needed?
> > >
> > > Good question Vivek?
>
> - IMA did not have any method to lock down signed binary pages in memory.
> So while contents on disk could be verified, one could still modify
> process memory contents by modifying swap. And IMA does not seem to
> have any mechanism to protect against that.

The kernel itself protects executables from being modified by calling
try_module_get(). The call to security_bprm_check() is immediately
before this call.

> - Also I really could not figure out where does the private signing key
> lives. I got the impression that we need to trust installer and
> signing somehow happens at installation time. And we wanted signing
> to happen at build server and could not trust installer for that.

Dmitry's ima-evm-utils package signs files. Depending on the options,
both the EVM and IMA extended attributes are created.

> My understanding of IMA could be wrong. So it would help if you
> could list the exact steps about how to achieve the same goal using
> IMA.

http://linux-ima.sourceforge.net/ needs to be updated, but it describes
the integrity subsystem and includes a link to Dave Safford's original
whitepaper "An Overview of the Linux Integrity subsystem".

> > >
> > > I remeber there was a slight mismatch in the desired attributes. In
> > > particular we want signatures that are not generated on the local
> > > machine.
> >
> > Right, IMA-appraisal supports different methods of verification. The
> > initial methods are hash and digital signature stored in the extended
> > attribute. With the queued patches, we can force signature verification
> > to be of a specific type. It defines a new IMA policy option called
> > 'appraise_type='.
> >
> > > > With IMA-appraisal, there are a couple of issues that would still need
> > > > to be addressed:
> > > > - missing the ability to specify the validation method required.
> > > > - modify the ima_appraise_tcb policy policy to require elf executables
> > > > to be digitally signed.
> > > > - security_bprm_check() is called before the binary handler is known.
> > > >
> > > > The first issue is addressed by a set of patches queued to be upstreamed
> > > > in linux-integrity/next-ima-appraise-status.
> > > >
> > > > To address the last issue would either require moving the existing
> > > > bprm_check or defining a new hook after the binary handler is known.
> > >
> > > Even if there is a small mismatch it certainly sounds like something to
> > > investigate. There are a lot of pieces flying around with IMA so an
> > > appropriate model of what needs to happen isn't in my head. As opposed
> > > to a signature in an ELF executable and a key in the kernel.
> >
> > The original IMA was about measurement and attestation. IMA-appraisal
> > adds local integrity validation and enforcement of the measurement
> > against a "good" value stored as an extended attribute 'security.ima'.
> > The initial methods for validating 'security.ima' are hash and digital
> > signature based.
> >
> > > Hooks aside in an IMA world where does the signing key live? Where does
> > > the signature live?
> >
> > Initially, the public key used to verify the signature is loaded onto an
> > IMA specific keyring. We've discussed embedding public keys inside the
> > kernel, but haven't done so yet.
>
> So where does the signing key (private key) live? And when does actual
> signing happens and who does it.

The signing process is currently not part of kbuild, but a separate
process, as mentioned above.

> >
> > The next steps are to ensure the secure boot signature chain of trust
> > has not been broken.
>
> Yes this one is important. This will also include making sure root can
> not load/install its own keys until and unless new key is signed with
> one of existing keys. Otherwise chain of trust is broken.

Right.

thanks,

Mimi



\
 
 \ /
  Last update: 2013-01-16 17:22    [W:0.130 / U:2.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site