All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>,
	linux-kernel@vger.kernel.org, pjones@redhat.com, hpa@zytor.com,
	dhowells@redhat.com, jwboyer@redhat.com
Subject: Re: [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary
Date: Tue, 15 Jan 2013 23:55:59 -0500	[thread overview]
Message-ID: <1358312159.4593.37.camel@falcor1> (raw)
In-Reply-To: <871udloiku.fsf@xmission.com>

On Tue, 2013-01-15 at 20:30 -0800, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@redhat.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


  reply	other threads:[~2013-01-16  4:56 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-15 21:34 [PATCH 0/3] ELF executable signing and verification Vivek Goyal
2013-01-15 21:34 ` [PATCH 1/3] module: export couple of functions for use in process signature verification Vivek Goyal
2013-01-15 21:34 ` [PATCH 2/3] binfmt_elf: Verify signature of signed elf binary Vivek Goyal
2013-01-16  4:30   ` Eric W. Biederman
2013-01-16  4:55     ` Mimi Zohar [this message]
2013-01-16  7:10       ` Eric W. Biederman
2013-01-16 14:00         ` Mimi Zohar
2013-01-16 14:48           ` Vivek Goyal
2013-01-16 15:33             ` Mimi Zohar
2013-01-16 15:54               ` Vivek Goyal
2013-01-16 17:24                 ` Mimi Zohar
2013-01-16 18:21                   ` Vivek Goyal
2013-01-16 18:45                     ` Mimi Zohar
2013-01-16 18:57                       ` Vivek Goyal
2013-01-16 19:37                         ` Mimi Zohar
2013-01-16 19:47                           ` Vivek Goyal
2013-01-16 20:25                             ` Mimi Zohar
2013-01-16 21:55                               ` Vivek Goyal
2013-01-17  8:37                             ` Elena Reshetova
2013-01-17 14:39                     ` Kasatkin, Dmitry
2013-01-17 14:35                 ` Kasatkin, Dmitry
2013-01-16 16:34               ` Vivek Goyal
2013-01-16 18:08                 ` Mimi Zohar
2013-01-16 18:28                   ` Vivek Goyal
2013-01-16 19:24                     ` Mimi Zohar
2013-01-16 21:53                       ` Vivek Goyal
2013-01-17 14:58                         ` Kasatkin, Dmitry
2013-01-17 15:06                           ` Kasatkin, Dmitry
2013-01-17 15:21                             ` Vivek Goyal
2013-01-17 15:18                           ` Vivek Goyal
2013-01-17 16:27                             ` Kasatkin, Dmitry
2013-01-17 20:33                             ` Frank Ch. Eigler
2013-01-17 20:55                               ` Vivek Goyal
2013-01-17 21:46                                 ` Kasatkin, Dmitry
2013-01-17 21:52                                   ` Vivek Goyal
2013-01-20 16:36                                     ` Mimi Zohar
2013-01-21 16:42       ` Vivek Goyal
2013-01-21 18:30         ` Mimi Zohar
2013-01-16 22:35   ` Mimi Zohar
2013-01-16 22:51     ` Vivek Goyal
2013-01-16 23:16       ` Eric W. Biederman
2013-01-17 15:37   ` Mimi Zohar
2013-01-17 15:51     ` Vivek Goyal
2013-01-17 16:32       ` Mimi Zohar
2013-01-17 17:01         ` Kasatkin, Dmitry
2013-01-17 17:03           ` Kasatkin, Dmitry
2013-01-17 17:42           ` Vivek Goyal
2013-01-17 17:36         ` Vivek Goyal
2013-01-20 17:20           ` Mimi Zohar
2013-01-21 15:45             ` Vivek Goyal
2013-01-21 18:44               ` Mimi Zohar
2013-01-20 16:17         ` H. Peter Anvin
2013-01-20 16:55           ` Mimi Zohar
2013-01-20 17:00             ` H. Peter Anvin
2013-01-15 21:34 ` [PATCH 3/3] binfmt_elf: Do not allow exec() if signed binary has intepreter Vivek Goyal
2013-01-15 21:37 ` [PATCH 4/3] User space utility "signelf" to sign elf executable Vivek Goyal
2013-01-15 22:27 ` [PATCH 0/3] ELF executable signing and verification richard -rw- weinberger
2013-01-15 23:15   ` Vivek Goyal
2013-01-15 23:17     ` richard -rw- weinberger
2013-01-17 16:22 ` Kasatkin, Dmitry
2013-01-17 17:25   ` Vivek Goyal
2013-01-22  4:22 ` Rusty Russell

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=1358312159.4593.37.camel@falcor1 \
    --to=zohar@linux.vnet.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jwboyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pjones@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.