linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huawei.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: "tytso@mit.edu" <tytso@mit.edu>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"hughd@google.com" <hughd@google.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-fscrypt@vger.kernel.org" <linux-fscrypt@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"deven.desai@linux.microsoft.com"
	<deven.desai@linux.microsoft.com>,
	"wufan@linux.microsoft.com" <wufan@linux.microsoft.com>
Subject: RE: [RFC][PATCH 2/5] fsverity: Revalidate built-in signatures at file open
Date: Mon, 15 Nov 2021 09:42:09 +0000	[thread overview]
Message-ID: <ae418bcd4d074500b417b74af5db11b2@huawei.com> (raw)
In-Reply-To: <YY69NaucW+0t474Q@gmail.com>

> From: Eric Biggers [mailto:ebiggers@kernel.org]
> Sent: Friday, November 12, 2021 8:15 PM
> On Fri, Nov 12, 2021 at 01:44:08PM +0100, Roberto Sassu wrote:
> > Fsverity signatures are validated only upon request by the user by setting
> > the requirement through procfs or sysctl.
> >
> > However, signatures are validated only when the fsverity-related
> > initialization is performed on the file. If the initialization happened
> > while the signature requirement was disabled, the signature is not
> > validated again.
> 
> I'm not sure this really matters.  If someone has started using a verity file
> before the require_signatures sysctl was set, then there is already a race
> condition; this patch doesn't fix that.  Don't you need to set the
> require_signatures sysctl early enough anyway?

Yes, access to already opened files is not revoked. It will work
for a new open. Actually, the main reason for this patch was that
one of the tests in xfstests-dev fails (generic/577).

While persistent filesystems are unmounted and mounted before
the test, which causes the fsverity_info structure to be removed
from the inode, requiring a new verification, tmpfs is just remounted.
During remount, the fsverity_info structure of already instantiated
inodes is kept.

Since fsverity_verify_signature() is called only when the
fsverity_info structure is created, all files with that structure are
considered valid, even if signature verification was temporarily
disabled at the time the structure was created.

Requiring signature verification early could be a solution, but
it is still at discretion of root. Maybe it would be a good idea to
disable the interface with a kernel option, so that signatures
can be enforced in a mandatory way.

This patch probably helps more LSMs, by exposing the information
of whether the signature was validated, to make their decision
depending on their policy.

Thanks

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua

  reply	other threads:[~2021-11-15  9:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-12 12:44 [RFC][PATCH 0/5] shmem/fsverity: Prepare for mandatory integrity enforcement Roberto Sassu
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 [this message]
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=ae418bcd4d074500b417b74af5db11b2@huawei.com \
    --to=roberto.sassu@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=deven.desai@linux.microsoft.com \
    --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 \
    --cc=wufan@linux.microsoft.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 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).