Re: [PATCH v2] fsverity: improve documentation for builtin signature support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux