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 v3 4/4] fuse: define the filesystem as untrusted
Date: Thu, 15 Mar 2018 17:24:07 -0400	[thread overview]
Message-ID: <1521149047.3547.674.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180314225338.GA147255@google.com>

On Wed, 2018-03-14 at 15:53 -0700, Michael Halcrow wrote:
> On Wed, Mar 14, 2018 at 04:42:51PM -0500, Eric W. Biederman wrote:
> > In this case I mean trust as in the believe that the server is not
> > actively trying to subvert the guarantees that IMA is depending
> > upon.
> 
> The fs-verity adversarial model we're targeting includes a malicious
> layer backing the local file system inode's page cache.
> 
> For example, the malicious layer can be a drive controller with
> trojaned firmware or a compromised remote server.
> 
> > What happens if the server on the first read returns an innocuous
> > file that matches it's ima xattr, but on the next read of the file
> > returns an evil trojan horse.  Or what if the server implements a
> > cache coherency protocol but lies and does not report all of the
> > changes to a file.
> 
> fs-verity validates each page in the inode's page cache against the
> inode's root-of-trust every time the page is read into the cache.
> 
> The signature mechanism on the root-of-trust must bind the inode
> identity.
> 
> The initial version of fs-verity supports Secure Boot, and the TCB
> validates each inode identity in the mount during the boot process.
> fs-verity does this via an ioctl that provisions the fs-verity
> measurement, causing the inode (along with its immutable measurement)
> to be pinned by the superblock for the life of the mount.  This meets
> requirements for the Android platform's use case, which only needs to
> cover about 15 APKs during boot.
> 
> This doesn't scale.  Future work will include integration with PKCS7
> and/or IMA.  Signatures will be dynamically verifiable against a key
> or keys in the TCB, and I'd like to establish a safe way to avoid
> having to pin inodes and their measurements.

Next steps should also include identifying methods for storing and
transporting the Merkle tree signature without having to read the
entire file for remote filesystems.

With this fs support, signed files on file systems mounted with the
?SB_I_IMA_UNVERIFIABLE_SIGNATURE flag would then be verifiable. ?

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-03-15 21:24 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-08 20:24 [PATCH v3 0/4] unverifiable file signatures Mimi Zohar
2018-03-08 20:24 ` [PATCH v3 1/4] ima: fail file signature verification on non-init mounted filesystems Mimi Zohar
2018-03-12 19:17   ` Serge E. Hallyn
2018-03-12 19:26     ` Serge E. Hallyn
2018-03-13 18:45   ` Eric W. Biederman
2018-03-08 20:24 ` [PATCH v3 2/4] ima: re-evaluate files on privileged " Mimi Zohar
2018-03-12 19:18   ` Serge E. Hallyn
2018-03-13 19:24   ` Eric W. Biederman
2018-03-08 20:24 ` [PATCH v3 3/4] ima: fail signature verification based on policy Mimi Zohar
2018-03-12 19:28   ` Serge E. Hallyn
2018-03-12 19:32     ` Mimi Zohar
2018-03-13 19:31   ` Eric W. Biederman
2018-03-08 20:24 ` [PATCH v3 4/4] fuse: define the filesystem as untrusted Mimi Zohar
2018-03-12 19:29   ` Serge E. Hallyn
2018-03-13 14:46     ` Stefan Berger
2018-03-14 14:27       ` Serge E. Hallyn
2018-03-14 14:37         ` Stefan Berger
2018-03-13 19:32   ` Eric W. Biederman
2018-03-19 11:57     ` Mimi Zohar
2018-03-14  7:52   ` Stef Bon
2018-03-14 13:01     ` Mimi Zohar
2018-03-14 16:17       ` Eric W. Biederman
2018-03-14 17:50         ` Mimi Zohar
2018-03-14 18:08           ` Chuck Lever
2018-03-14 19:46             ` Eric W. Biederman
2018-03-14 20:34               ` Chuck Lever
2018-03-14 21:42                 ` Eric W. Biederman
2018-03-14 22:53                   ` Michael Halcrow
2018-03-15 21:24                     ` Mimi Zohar [this message]
2018-03-15 10:07                   ` Stef Bon
2018-03-15 13:53                     ` Chuck Lever
2018-03-15 22:05               ` Mimi Zohar
2018-03-13 19:40 ` [PATCH v3 0/4] unverifiable file signatures Eric W. Biederman
2018-03-13 20:40   ` 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=1521149047.3547.674.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).