On Mon, 19 Jun 2023 at 23:11, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > fsverity builtin signatures (CONFIG_FS_VERITY_BUILTIN_SIGNATURES) aren't > the only way to do signatures with fsverity, and they have some major > limitations. Yet, more users have tried to use them, e.g. recently by > https://github.com/ostreedev/ostree/pull/2640. In most cases this seems > to be because users aren't sufficiently familiar with the limitations of > this feature and what the alternatives are. > > Therefore, make some updates to the documentation to try to clarify the > properties of this feature and nudge users in the right direction. > > Note that the Integrity Policy Enforcement (IPE) LSM, which is not yet > upstream, is planned to use the builtin signatures. (This differs from > IMA, which uses its own signature mechanism.) For that reason, my > earlier patch "fsverity: mark builtin signatures as deprecated" > (https://lore.kernel.org/r/20221208033548.122704-1-ebiggers@xxxxxxxxxx), > which marked builtin signatures as "deprecated", was controversial. > > This patch therefore stops short of marking the feature as deprecated. > I've also revised the language to focus on better explaining the feature > and what its alternatives are. > > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> > --- > > v2: updated two paragraphs of fsverity.rst to address Luca's comments > > Documentation/filesystems/fsverity.rst | 190 ++++++++++++++++--------- > fs/verity/Kconfig | 16 +-- > fs/verity/enable.c | 2 +- > fs/verity/open.c | 8 +- > fs/verity/read_metadata.c | 4 +- > fs/verity/signature.c | 8 ++ > 6 files changed, 147 insertions(+), 81 deletions(-) > > diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst > index ede672dedf110..c33f783e74953 100644 > --- a/Documentation/filesystems/fsverity.rst > +++ b/Documentation/filesystems/fsverity.rst <...> > +- Trusted userspace code. Often, the userspace code that accesses > + files can be trusted to authenticate them. Consider e.g. an > + application that wants to authenticate data files before using them, > + or an application loader that is part of the operating system (which > + is already authenticated in a different way, such as by being loaded > + from a read-only partition that uses dm-verity) and that wants to > + authenticate applications before loading them. In these cases, this > + trusted userspace code can authenticate a file's contents by > + retrieving its fs-verity digest using `FS_IOC_ENABLE_VERITY`_, then > + verifying a signature of it using any userspace cryptographic > + library that supports digital signatures. Consider using `libsodium > + <https://libsodium.gitbook.io/doc/public-key_cryptography/public-key_signatures>`_ > + or `Tink <https://developers.google.com/tink/digitally-sign-data>`_. > + Other options include OpenSSL, JCA, and libgcrypt. Text looks good to me now, but please just drop the last sentence with the external projects links, as it seems best left as an exercise for the reader to find their preferred tooling that is appropriate to be used at the time of reading, as this will get out of date fast. <...> > +- fs-verity builtin signatures are in PKCS#7 format, and the public > + keys are in X.509 format. These data formats are unnecessarily > + complex and prone to vulnerabilities. (fs-verity builtin signatures > + were made to use these formats because other kernel subsystems, such > + as the module loader, unfortunately used these formats already. > + Note, these formats should still be used when they are the only > + option to have signatures at all.) Userspace signature verification > + avoids having to enable CONFIG_FS_VERITY_BUILTIN_SIGNATURES and the > + associated kernel attack surface. Userspace also has the > + flexibility to choose simpler formats. For example, consider using > + straightforward Ed25519 keys and signatures with `libsodium > + <https://libsodium.gitbook.io/doc/public-key_cryptography/public-key_signatures>`_. > + > + IMA appraisal, which supports fs-verity, does not use PKCS#7, so it > + partially avoids this issue as well (though it does use X.509). > + > + If you are considering making use of "advanced" features of X.509 > + and/or PKCS#7, please also keep in mind that these "advanced" > + features do not always work as intended with the kernel. For > + example, the kernel does not check X.509 certificate validity times. Sorry but this still reads as way too opinionated and generic, rather than being fsverity-specific. Please simplify to convey the same message in more concise way, perhaps something along these lines: - fs-verity builtin signatures are in PKCS#7 format, and the public keys are in X.509 format. IMA appraisal, which supports fs-verity, uses a custom signature format rather than PKCS#7 and X.509 for public keys. Alternative formats for signatures and public keys are not supported for builtin signatures or IMA appraisal. For fully flexible and customized signature and public keys formats, while also avoiding to expose the kernel to untrusted input, signature verification can be implemented by a trusted userspace component as described at <pointer to appropriate section> Kind regards, Luca Boccassi
