On Tue, 20 Jun 2023 at 13:59, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2023-06-20 at 01:42 +0100, Luca Boccassi wrote: > > On Tue, 20 Jun 2023 at 00:49, Eric Biggers <ebiggers@xxxxxxxxxx> > > wrote: > > > On Tue, Jun 20, 2023 at 12:04:39AM +0100, Luca Boccassi wrote: > [...] > > > > > +- 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/publi > > > > > c-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> > > > > > > That is not the same message at all, as it omits the mention of the > > > disadvantages of PKCS#7 and X.509 compared to raw signatures, which > > > was the main point. So no, I don't think your version would be > > > better. > > > > The 'disadvantages' are your personal opinions. It's fine to have > > opinions, it's less fine to present them as if they were industry > > consensus in public project-wide documentation. > > > > > It seems that what is going on here is that you are invested > > > heavily into existing X.509 and PKCS#7 based systems, and as a > > > result you do not want the problems with these formats to be > > > described anywhere in the kernel documentation. That is > > > understandable, but that is a special interest that should not be > > > catered to here. This documentation is trying to help users make > > > a decision of what type of signature to use in new systems. And > > > yes, it is fsverity specific documentation, but there is no way for > > > it to make the needed point without dicussing the underlying data > > > formats. > > > > Industry standards are by very definition the opposite of 'special > > interests'. Look, I tried my best to provide constructive and > > actionable feedback in previous replies, but given you seem only > > interested in casting aspersions and hijacking kernel documentation > > to promote the latest proprietary google-toy-of-the-month: > > OK, could I try to share the perspective of of someone who's worked in > security with users for a long time. I get that every security expert > thinks standard key formats are insecure, usually for two reasons > > 1. In security simpler is better > 2. They can always come up with a simple, totally secure, key > representation > > The problem with the above is that it means every tool invented by a > different security expert has a different key format and we don't have > any interoperability between them. This is great from a security point > of view but terrible for usability: users want both interoperability > and pluggability (particularly the ability to use tokens or other > security devices in place of keys). Our security systems are not coded > for absolute security (otherwise they would be completely balkanized); > they're a tradeoff between usability and security. There's actually > even a security reason for this: a security tool no-one can use isn't > contributing to the security of the ecosystem, however internally > secure and up to date the tool is. It's not just Google who has a habit > of special coding security systems to work on Android (with Titan-M), I > can't use wireguard on Linux because I long ago mandated that critical > things like VPN keys should be in secure keystores and I use the TPM on > Linux for openvpn. Wireguard, because it has a simple and secure key > format, won't plug into the kernel TPM system without a whole load of > speciallised glue, so I'm stuck with openvpn. > > The debate you two are having now is about the most important thing we > can ever decide: where to draw the line between usability and security. > If you conduct it in a more constructive manner and try to see each > other's point of view (Eric: how would I use a TPM with fsverity on > Linux? and Luca: how much interoperability does fsverity really need > for debian?) because usability without security is as equally useless > as security without usability. You make very good points, it's always about finding compromises. For my use case, interoperability is fundamental: if I needed to have a completely different infrastructure, signing, tooling and maintenance strategy for dm-verity, fs-verity, kernel modules, livepatching, UEFI, TPM signed policies and who knows what else, I'd lose my mind. But I am happy to compromise and ack the latest revision, and I've already done so. Kind regards, Luca Boccassi
