linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: zohar@linux.vnet.ibm.com (Mimi Zohar)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v1 1/2] ima: fail signature verification on untrusted filesystems
Date: Wed, 21 Feb 2018 09:46:19 -0500	[thread overview]
Message-ID: <1519224379.3736.154.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180220201636.GA1565@mail.hallyn.com>

> > > On the flip side when it really is a trusted mounter, and it is in a
> > > configuration that IMA has a reasonable expectation of seeing all of
> > > the changes it would be nice if we can say please trust this mount.
> > 
> > IMA has no way of detecting file change. ?This was one of the reasons
> > for the original patch set's not using the cached IMA results.
> > 
> > Even in the case of a trusted mounter and not using IMA cached
> > results, there are no guarantees that the data read to calculate the
> > file hash, will be the same as what is subsequently read. ?In some
> > environments this might be an acceptable risk, while in others not.
> 
> So for the cases where it's not, there should be an IMA option or policy
> to say any SB_I_IMA_UNVERIFIABLE_SIGNATURES mounts should be not
> trusted, with the default being both SB_I_IMA_UNVERIFIABLE_SIGNATURES and
> SB_I_UNTRUSTED_MOUNTER must be true to not trust, right?

Right. ?To summarize, we've identified 3 scenarios:
1. Fail signature verification on unprivileged non-init root mounted
file systems.

flags: SB_I_IMA_UNVERIFIABLE_SIGNATURES and SB_I_UNTRUSTED_MOUNTER
(always enabled)

2. Permit signature verification on privileged file system mounts in a
secure system environment. ?Willing to accept the risk. ?Does not rely
on cached integrity results, but forces re-evaluation.

flags: SB_I_IMA_UNVERIFIABLE_SIGNATURES, not SB_I_UNTRUSTED_MOUNTER or
IMA_FAIL_UNVERIFICABLE_SIGNATURES (default behavior)

3. Fail signature verification also on privileged file system mounts.
Fail safe, unwilling to accept the risk.

flags:
SB_I_IMA_UNVERIFIABLE_SIGNATURES and IMA_FAIL_UNVERIFIABLE_SIGNATURES

Enabled by specifying "ima_policy=unverifiable_sigs" on the boot
command line.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2018-02-21 14:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-19 15:18 [PATCH v1 0/2] ima: untrusted filesystems Mimi Zohar
2018-02-19 15:18 ` [PATCH v1 1/2] ima: fail signature verification on " Mimi Zohar
2018-02-19 21:47   ` Eric W. Biederman
2018-02-20  0:52     ` James Morris
2018-02-20  2:02       ` Eric W. Biederman
2018-02-20 14:02         ` Mimi Zohar
2018-02-20 20:16           ` Serge E. Hallyn
2018-02-21 14:46             ` Mimi Zohar [this message]
2018-02-21 22:46               ` Eric W. Biederman
2018-02-21 22:57                 ` Mimi Zohar
2018-02-21 23:12                   ` Eric W. Biederman
2018-02-21 23:32                     ` Mimi Zohar
2018-02-27  2:12                       ` Eric W. Biederman
2018-02-21 22:53           ` Eric W. Biederman
2018-02-21 23:03             ` Mimi Zohar
2018-02-19 22:50   ` kbuild test robot
2018-02-19 23:36   ` kbuild test robot
2018-02-19 15:18 ` [PATCH v1 2/2] fuse: define the filesystem as untrusted 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=1519224379.3736.154.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=linux-security-module@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).