From: Vivek Goyal <vgoyal@redhat.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: "Kasatkin, Dmitry" <dmitry.kasatkin@intel.com>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] ima: Support appraise_type=imasig_optional
Date: Thu, 14 Feb 2013 15:57:20 -0500 [thread overview]
Message-ID: <20130214205720.GH16671@redhat.com> (raw)
In-Reply-To: <20130214205445.GG16671@redhat.com>
On Thu, Feb 14, 2013 at 03:54:45PM -0500, Vivek Goyal wrote:
> On Thu, Feb 14, 2013 at 02:49:16PM -0500, Mimi Zohar wrote:
>
> [..]
> > > > I think you're making this more complicated than it needs to be. Allow
> > > > the execution unless the file failed signature verification. The
> > > > additional capability is given only if the signature verification
> > > > succeeds.
> > >
> > > I am just trying to bring it inline with module signature verification.
> > > There also module loading fails if signatures are present but kernel
> > > can't verify it.
> >
> > A specific hook is defined for kernel module signature verification,
> > which is enabled/disabled in Kconfig. When enabled, only signed modules
> > are loaded. The kernel module hook does not verify the integrity of the
> > userspace application (eg. insmod, modprobe), but of the kernel module
> > being loaded.
> >
> > Your original patches verified the integrity of the userspace
> > application kexec, not the image being loaded. ima_bprm_check()
> > verifies the integrity of executables. To permit both signed and
> > unsigned files to execute, we defined the 'optional' IMA policy flag,
> > with the intention of giving more capability to signed executables.
> >
> > Unless we define a kexec specific hook for verifying kernel images, it's
> > not the same.
>
> I think we are talking of two different things here.
>
> I am referring to kernel module signing where signatures are appended
> to module (not IMA hook).
>
> Also I am just referring to behavior about what happens if some error
> happens while signature verification.
>
> - If signature verification fails, it is clear what to do.
> - If signature verification passes, it is clear what to do.
> - Grey area is, what happens if some error is encountered during signature
> verification. Should the module loading be allowed/disallowed. Looking
> at the module loading code, once it is determined that module has
> signature appended to it, module loading fails if some error occurs
> during signature verification.
>
> So I am just referring to that fact and trying to draw parallels between
> error handling during module signature verification and error handling
> when file appraisal happens in IMA.
>
> There can be two options.
>
> - Disallow execution only if signature verification fails. If some error
> happens during verification, ignore it, let the executable continue.
> Just that it does not get extra capability.
>
> - Disallow execution only if executable is not signed or it has valid
> signature. If executable is signed and some error happens during the
> process of verifying signature, execution is denied.
>
Little typo in second option. I meant "Allow execution only if executable
is not signed or it has valid signatures".
Thanks
Vivek
next prev parent reply other threads:[~2013-02-14 20:57 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-11 20:11 [RFC PATCH 0/2] ima: Support a mode to appraise signed files only Vivek Goyal
2013-02-11 20:11 ` [PATCH 1/2] ima: Do not try to fix hash if file system does not support security xattr Vivek Goyal
2013-02-12 11:45 ` Mimi Zohar
2013-02-12 14:27 ` Vivek Goyal
2013-02-11 20:11 ` [PATCH 2/2] ima: Support appraise_type=imasig_optional Vivek Goyal
2013-02-11 22:10 ` Mimi Zohar
2013-02-12 14:26 ` Vivek Goyal
2013-02-12 17:14 ` Mimi Zohar
2013-02-12 18:52 ` Vivek Goyal
2013-02-12 18:57 ` Vivek Goyal
2013-02-13 12:14 ` Kasatkin, Dmitry
2013-02-13 13:29 ` Vivek Goyal
2013-02-13 13:36 ` Kasatkin, Dmitry
2013-02-13 13:49 ` Vivek Goyal
2013-02-13 14:03 ` Mimi Zohar
2013-02-13 14:38 ` Vivek Goyal
2013-02-13 15:26 ` Kasatkin, Dmitry
2013-02-13 15:29 ` Kasatkin, Dmitry
2013-02-13 15:39 ` Vivek Goyal
2013-02-13 15:30 ` Vivek Goyal
2013-02-13 22:27 ` Mimi Zohar
2013-02-14 15:03 ` Vivek Goyal
2013-02-14 15:30 ` Mimi Zohar
2013-02-18 18:21 ` Vivek Goyal
2013-02-19 21:54 ` Mimi Zohar
2013-02-13 15:51 ` Mimi Zohar
2013-02-12 20:05 ` Mimi Zohar
2013-02-13 12:31 ` Kasatkin, Dmitry
2013-02-13 12:56 ` Mimi Zohar
2013-02-13 13:13 ` Kasatkin, Dmitry
2013-02-13 13:44 ` Mimi Zohar
2013-02-13 16:59 ` Vivek Goyal
2013-02-14 12:57 ` Mimi Zohar
2013-02-14 15:23 ` Vivek Goyal
2013-02-14 15:35 ` Mimi Zohar
2013-02-14 16:17 ` Vivek Goyal
2013-02-14 16:31 ` Vivek Goyal
2013-02-14 19:49 ` Mimi Zohar
2013-02-14 20:54 ` Vivek Goyal
2013-02-14 20:57 ` Vivek Goyal [this message]
2013-02-14 21:54 ` Mimi Zohar
2013-02-13 17:33 ` Kasatkin, Dmitry
2013-02-13 17:51 ` Vivek Goyal
2013-02-13 18:20 ` Kasatkin, Dmitry
2013-02-13 21:45 ` Mimi Zohar
2013-02-14 14:40 ` Vivek Goyal
2013-02-14 15:48 ` Mimi Zohar
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=20130214205720.GH16671@redhat.com \
--to=vgoyal@redhat.com \
--cc=dmitry.kasatkin@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=zohar@linux.vnet.ibm.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.