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:	Tue, 15 Jan 2013 23:55: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
Subject: Re: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary

On Tue, 2013-01-15 at 20:30 -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@...hat.com> writes:
> 
> > If a binary is signed, verify its signature. If signature is not valid, do
> > not allow execution. If binary is not signed, execution is allowed
> > unconditionally.
> >
> > CONFIG_BINFMT_ELF_SIGNATURE controls whether elf binary signature support
> > is compiled in or not.
> >
> > Signature are expected to be present in elf section ".section". This code
> > is written along the lines of module signature verification code. Just
> > that I have removed the magic string. It is not needed as signature is
> > expected to be present in a specific section.
> >
> > I put the signature into a section, instead of appending it so that
> > strip operation works fine.
> >
> > One signs and verifies  all the areas mapped by PT_LOAD segments of elf
> > binary. Typically Elf header is mapped in first PT_LOAD segment. As adding
> > .signature section can change three elf header fields (e_shoff, e_shnum
> > and e_shstrndx), these fields are excluded from digest calculation
> 
> My gut feel says that a signature that we verify should reside in an ELF
> segment.  Sections are for the linker not the kernel.
> 
> I don't totally know what the signature should cover but my gut feels
> says the signature should come after ever non-signature segment and
> cover all of the prior segments (PT_LOAD or not).  Because presumably
> the loader needs to look at everything in a segment.  We can
> restrict ourselves to only processing signed binaries on executables
> with only PT_LOAD segments and signatures for now.

Please remind me why you can't use IMA-appraisal, which was upstreamed
in Linux 3.7?  Why another method is needed?

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.

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/