linux-kernel - Re: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Jan 2013 09:00:59 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>, linux-kernel@...r.kernel.org,
	pjones@...hat.com, hpa@...or.com, dhowells@...hat.com,
	jwboyer@...hat.com, Dmitry Kasatkin <dmitry.kasatkin@...el.com>
Subject: Re: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary

On Tue, 2013-01-15 at 23:10 -0800, Eric W. Biederman wrote:
> Mimi Zohar <zohar@...ux.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?  
> 
> 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.

The next steps are to ensure the secure boot signature chain of trust
has not been broken.

(I've cc'ed Dmitry Kasatkin on this discussion.  It would also be
appropriate to cc the LSM mailing list.)

thanks,

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/