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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871udloiku.fsf@xmission.com>
Date:	Tue, 15 Jan 2013 20:30:41 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	linux-kernel@...r.kernel.org, zohar@...ux.vnet.ibm.com,
	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

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.

Eric
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ