From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
James Morris <jmorris@namei.org>,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
Seth Forshee <seth.forshee@canonical.com>,
Dongsu Park <dongsu@kinvolk.io>, Alban Crequy <alban@kinvolk.io>
Subject: Re: [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
WARNING: multiple messages have this Message-ID (diff)
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
WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
James Morris <jmorris@namei.org>,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
Seth Forshee <seth.forshee@canonical.com>,
Dongsu Park <dongsu@kinvolk.io>, Alban Crequy <alban@kinvolk.io>
Subject: Re: [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
next prev parent reply other threads:[~2018-02-21 14:46 UTC|newest]
Thread overview: 48+ 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 ` Mimi Zohar
2018-02-19 15:18 ` [PATCH v1 1/2] ima: fail signature verification on " Mimi Zohar
2018-02-19 15:18 ` Mimi Zohar
2018-02-19 21:47 ` Eric W. Biederman
2018-02-19 21:47 ` Eric W. Biederman
2018-02-20 0:52 ` James Morris
2018-02-20 0:52 ` James Morris
2018-02-20 2:02 ` Eric W. Biederman
2018-02-20 2:02 ` Eric W. Biederman
2018-02-20 14:02 ` Mimi Zohar
2018-02-20 14:02 ` Mimi Zohar
2018-02-20 14:02 ` Mimi Zohar
2018-02-20 20:16 ` Serge E. Hallyn
2018-02-20 20:16 ` Serge E. Hallyn
2018-02-20 20:16 ` Serge E. Hallyn
2018-02-21 14:46 ` Mimi Zohar [this message]
2018-02-21 14:46 ` Mimi Zohar
2018-02-21 14:46 ` Mimi Zohar
2018-02-21 22:46 ` Eric W. Biederman
2018-02-21 22:46 ` Eric W. Biederman
2018-02-21 22:46 ` Eric W. Biederman
2018-02-21 22:57 ` Mimi Zohar
2018-02-21 22:57 ` Mimi Zohar
2018-02-21 22:57 ` Mimi Zohar
2018-02-21 23:12 ` Eric W. Biederman
2018-02-21 23:12 ` Eric W. Biederman
2018-02-21 23:12 ` Eric W. Biederman
2018-02-21 23:32 ` Mimi Zohar
2018-02-21 23:32 ` Mimi Zohar
2018-02-21 23:32 ` Mimi Zohar
2018-02-27 2:12 ` Eric W. Biederman
2018-02-27 2:12 ` Eric W. Biederman
2018-02-27 2:12 ` Eric W. Biederman
2018-02-21 22:53 ` Eric W. Biederman
2018-02-21 22:53 ` Eric W. Biederman
2018-02-21 22:53 ` Eric W. Biederman
2018-02-21 23:03 ` Mimi Zohar
2018-02-21 23:03 ` Mimi Zohar
2018-02-21 23:03 ` Mimi Zohar
2018-02-19 22:50 ` kbuild test robot
2018-02-19 22:50 ` kbuild test robot
2018-02-19 22:50 ` kbuild test robot
2018-02-19 23:36 ` kbuild test robot
2018-02-19 23:36 ` 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
2018-02-19 15:18 ` 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=alban@kinvolk.io \
--cc=dongsu@kinvolk.io \
--cc=ebiederm@xmission.com \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=serge@hallyn.com \
--cc=seth.forshee@canonical.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.