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:

quoted

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