[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ae418bcd4d074500b417b74af5db11b2@huawei.com>
Date: Mon, 15 Nov 2021 09:42:09 +0000
From: Roberto Sassu <roberto.sassu@...wei.com>
To: Eric Biggers <ebiggers@...nel.org>
CC: "tytso@....edu" <tytso@....edu>, "corbet@....net" <corbet@....net>,
"viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
"hughd@...gle.com" <hughd@...gle.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-fscrypt@...r.kernel.org" <linux-fscrypt@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"deven.desai@...ux.microsoft.com" <deven.desai@...ux.microsoft.com>,
"wufan@...ux.microsoft.com" <wufan@...ux.microsoft.com>
Subject: RE: [RFC][PATCH 2/5] fsverity: Revalidate built-in signatures at file
open
> From: Eric Biggers [mailto:ebiggers@...nel.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
Powered by blists - more mailing lists