linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huawei.com>
To: <ebiggers@kernel.org>, <tytso@mit.edu>, <corbet@lwn.net>,
	<viro@zeniv.linux.org.uk>, <hughd@google.com>,
	<akpm@linux-foundation.org>
Cc: <linux-fscrypt@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-fsdevel@vger.kernel.org>, <linux-mm@kvack.org>,
	<linux-integrity@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Roberto Sassu <roberto.sassu@huawei.com>
Subject: [RFC][PATCH 0/5] shmem/fsverity: Prepare for mandatory integrity enforcement
Date: Fri, 12 Nov 2021 13:44:06 +0100	[thread overview]
Message-ID: <20211112124411.1948809-1-roberto.sassu@huawei.com> (raw)

The biggest advantage of fsverity compared to file-based solutions like IMA
is the lower overhead added for integrity measurement and enforcement.
Although fsverity offers the same file representation as a digest, it works
instead at page granularity rather than file granularity. Only the pages
that are going to be used will be evaluated by fsverity, while IMA has to
read the whole file.

Although fsverity has a built-in enforcement mechanism, it is basically
discretionary, it can be enabled (or disabled by replacing the file) by
the user himself. A mandatory mechanism could be used to impose fsverity
protection for files involved in certain events, defined with a policy.

Integrity Policy Enforcement (IPE) is one of such mandatory mechanisms
designed to work in conjunction with fsverity (IMA integration is planned).
However, at this stage (v7), IPE is storing fsverity data at file
instantiation time rather than at usage time. One disadvantage of such
approach is that a security blob needs to be allocated and maintained for
such purpose, which makes the code unnecessarily more complex. A much
better approach would be to retrieve the information when needed, without
storing it in a security blob.

Another gap that currently limits the applicability of fsverity is the
missing support for the tmpfs filesystem. Files could still be executed
from it (e.g. during the boot process) and would still need to be verified
by IPE. Not verifying those files would considerably reduce the
effectiveness of the integrity protection. Alternatively, requiring that
the initial ram disk is signed limits the applicability of the solution
only to embedded systems, where the initial ram disk can be also
distributed. General purpose OSes instead regenerate it locally depending
on the system configuration, and after critical packages changes.

Given that tmpfs is not persistent, the question is if support should be
implemented in a similar way of persistent filesystems, such as ext4. And,
while fsverity protection needs to be enabled on a file each time a tmpfs
filesystem is mounted, probably implementing fsverity support in the same
way is simpler.

Another question is whether and when pages should be checked. In a
preliminary test, checking a page after it was swapped in resulted in the
page not being considered valid by fsverity. For now there are no calls to
fsverity_verify_page().

The implementation in this patch set is not necessarily the most efficient,
and does not consider the specific features of tmpfs. The goal was to aim
at correctness, by following closely the implementation for f2fs, doing the
minimal changes necessary to make it work for tmpfs (e.g. replacing
read_mapping_page() with shmem_read_mapping_page()).

Other than with trivial operations, this patch set has been tested with
the xfstests-dev testsuite, also under severe memory pressure to ensure
that everything still works when a page is swapped out.

Make the following changes: provide the fsverity_get_file_digest() and
fsverity_sig_validated() for IPE to retrieve fsverity information at usage
time, and additionally revalidate the signature at every file open
(patches 1, 2); make fsverity suitable to protect files in the rootfs
filesystem (patch 3); fix a small problem in shmem_read_mapping_page_gfp()
(patch 4) and finally add support for fsverity in tmpfs (patch 5).

An open point, not addressed by this patch set, is how to enable the
fsverity protection for files in the rootfs filesystem, given that it is
too early for user space to invoke the ioctl() system call. It should not
be a problem to enable fsverity from the kernel, depending on a labelling
policy.

Roberto Sassu (5):
  fsverity: Introduce fsverity_get_file_digest()
  fsverity: Revalidate built-in signatures at file open
  fsverity: Do initialization earlier
  shmem: Avoid segfault in shmem_read_mapping_page_gfp()
  shmem: Add fsverity support

 Documentation/filesystems/fsverity.rst |  18 ++
 MAINTAINERS                            |   1 +
 fs/Kconfig                             |   7 +
 fs/verity/enable.c                     |   6 +-
 fs/verity/fsverity_private.h           |   7 +-
 fs/verity/init.c                       |   2 +-
 fs/verity/open.c                       |  43 +++-
 fs/verity/signature.c                  |   6 +-
 include/linux/fsverity.h               |  16 ++
 include/linux/shmem_fs.h               |  27 +++
 mm/Makefile                            |   2 +
 mm/shmem.c                             |  71 ++++++-
 mm/shmem_verity.c                      | 267 +++++++++++++++++++++++++
 13 files changed, 463 insertions(+), 10 deletions(-)
 create mode 100644 mm/shmem_verity.c

-- 
2.32.0


             reply	other threads:[~2021-11-12 12:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-12 12:44 Roberto Sassu [this message]
2021-11-12 12:44 ` [RFC][PATCH 1/5] fsverity: Introduce fsverity_get_file_digest() Roberto Sassu
2021-11-12 12:44 ` [RFC][PATCH 2/5] fsverity: Revalidate built-in signatures at file open Roberto Sassu
2021-11-12 19:15   ` Eric Biggers
2021-11-15  9:42     ` Roberto Sassu
2021-11-12 12:44 ` [RFC][PATCH 3/5] fsverity: Do initialization earlier Roberto Sassu
2021-11-12 12:44 ` [RFC][PATCH 4/5] shmem: Avoid segfault in shmem_read_mapping_page_gfp() Roberto Sassu
2021-11-12 12:53   ` Ajay Garg
2021-11-12 12:56     ` Roberto Sassu
2021-11-12 18:56   ` Eric Biggers
2021-11-15  8:02     ` Roberto Sassu
2021-11-12 12:44 ` [RFC][PATCH 5/5] shmem: Add fsverity support Roberto Sassu
2021-11-12 19:12   ` Eric Biggers
2021-11-15  8:49     ` Roberto Sassu
2021-11-15 19:05       ` Eric Biggers
2021-11-16 10:43         ` Roberto Sassu

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=20211112124411.1948809-1-roberto.sassu@huawei.com \
    --to=roberto.sassu@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=ebiggers@kernel.org \
    --cc=hughd@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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).