All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, dmitry.kasatkin@intel.com
Subject: Re: [PATCH 2/6] ima: Return INTEGRITY_FAIL if digital signature can't be verified
Date: Tue, 05 Mar 2013 08:30:53 -0500	[thread overview]
Message-ID: <1362490253.4392.159.camel@falcor1> (raw)
In-Reply-To: <20130304162033.GB15199@redhat.com>

On Mon, 2013-03-04 at 11:20 -0500, Vivek Goyal wrote:
> On Mon, Mar 04, 2013 at 08:48:36AM -0500, Mimi Zohar wrote:
> > On Thu, 2013-02-14 at 14:55 -0500, Vivek Goyal wrote:
> > > Digital signature verification happens using integrity_digsig_verify().
> > > Curently we set integrity to FAIL for all error codes except -EOPNOTSUPP.
> > > This sounds out of line.
> > > 
> > > - If appropriate kernel code is not compiled in to verify signature of
> > >   a file, then prractically it is a failed signature.
> > > 
> > > - For so many other possible errors we are setting the status to fail.
> > >   For example, -EINVAL, -ENOKEY, -ENOMEM, -EINVAL, -ENOTSUPP etc, it
> > >   beats me that why -EOPNOTSUPP is special.
> > > 
> > > This patch should make the semantics more consistent. That is, if digital
> > > signature is present in security.ima, then any error happened during
> > > signature processing leads to status INTEGRITY_FAIL.
> > > 
> > > AFAICS, it should not have any user visible effect on existing
> > > application. In some cases we will start returning INTEGRITY_FAIL
> > > instead of INTEGRITY_UNKNOWN. And process_measurement() will deny access
> > > to file both in case of INTEGRITY_UNKNOWN and INTEGRITY_FAIL.
> > > 
> > > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> > 
> > A number of patches in this patchset more finely differentiate return
> > codes, which is good.  I agree with you totally that there is no good
> > reason for -EOPNOTSUPP to be handled differently.  Unfortunately, the
> > initramfs is CPIO, which doesn't support xattrs.  With the proposed
> > change and 'ima_appraise_tcb' flag enabled, we wouldn't be able to boot.
> > I really dislike hard coding policy in the kernel.
> 
> Hi Mimi,
> 
> If there are no xattr, then we will not even hit this code. We will
> bail out early in vfs_getxattr_alloc().
> 
> I thought that one of the DON_APPRAISE rules will kick in for initramfs
> and files in initramfs will not be appraised and boot will continue.
> 
> {.action = DONT_APPRAISE,.fsmagic = TMPFS_MAGIC,.flags = IMA_FSMAGIC},
> {.action = DONT_APPRAISE,.fsmagic = RAMFS_MAGIC,.flags = IMA_FSMAGIC},
> 
> Is that not the case here?

Right, thanks for the clarification.  Perhaps we could abbreviate the
patch description like:
 
Digital signature verification happens using integrity_digsig_verify().
If a digital signature is present in security.ima, then any error, which
happens during signature verification, should lead to status
INTEGRITY_FAIL.  In the future we might want to differentiate between
persistent (eg. -ENOMEM) vs. non-persistent errors, in order to cache
failures.  This patch removes the unnecessary -EOPNOTSUPP test.
 
thanks,

Mimi


  reply	other threads:[~2013-03-05 13:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-14 19:55 [RFC PATCH 0/6][v3] ima: Support a mode to appraise signed files only Vivek Goyal
2013-02-14 19:55 ` [PATCH 1/6] ima: detect security xattrs not enabled Vivek Goyal
2013-02-14 19:55 ` [PATCH 2/6] ima: Return INTEGRITY_FAIL if digital signature can't be verified Vivek Goyal
2013-03-04 13:48   ` Mimi Zohar
2013-03-04 16:20     ` Vivek Goyal
2013-03-05 13:30       ` Mimi Zohar [this message]
2013-03-05 13:54         ` Mimi Zohar
2013-03-05 15:35         ` Vivek Goyal
2013-02-14 19:55 ` [PATCH 3/6] ima/evm: Differentiate between ima/evm nolabel return code Vivek Goyal
2013-02-14 19:55 ` [PATCH 4/6] ima: Introduce new integrity error code INTEGRITY_XATTR_NOTSUPP Vivek Goyal
2013-02-14 19:55 ` [PATCH 5/6] ima: Allow appraisal of digitally signed files only Vivek Goyal
2013-03-05 19:13   ` Vivek Goyal
2013-03-07  7:44     ` Kasatkin, Dmitry
2013-02-14 19:55 ` [PATCH 6/6] ima: With appraise_type=optional, audit log some messages as info Vivek Goyal
2013-02-14 20:51 ` [RFC PATCH 0/6][v3] ima: Support a mode to appraise signed files only Mimi Zohar
2013-02-14 21:44   ` Vivek Goyal

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=1362490253.4392.159.camel@falcor1 \
    --to=zohar@linux.vnet.ibm.com \
    --cc=dmitry.kasatkin@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --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.