From: Luca Boccassi <bluca@debian.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Eric Biggers <ebiggers@kernel.org>,
fsverity@lists.linux.dev, linux-integrity@vger.kernel.org,
linux-doc@vger.kernel.org, Colin Walters <walters@verbum.org>,
Alexander Larsson <alexl@redhat.com>,
Victor Hsieh <victorhsieh@google.com>
Subject: Re: [PATCH v2] fsverity: improve documentation for builtin signature support
Date: Tue, 20 Jun 2023 20:34:58 +0100 [thread overview]
Message-ID: <CAMw=ZnQiu09jBsdbxxzyE3j98GqnmxxML+dwOQQs9kct1KZhWA@mail.gmail.com> (raw)
In-Reply-To: <b2ee0120b5f3caec6ddd617c1594cc05d66a6687.camel@HansenPartnership.com>
On Tue, 20 Jun 2023 at 13:59, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Tue, 2023-06-20 at 01:42 +0100, Luca Boccassi wrote:
> > On Tue, 20 Jun 2023 at 00:49, Eric Biggers <ebiggers@kernel.org>
> > 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
next prev parent reply other threads:[~2023-06-20 19:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-19 22:10 [PATCH v2] fsverity: improve documentation for builtin signature support Eric Biggers
2023-06-19 22:17 ` Eric Biggers
2023-06-19 23:04 ` Luca Boccassi
2023-06-19 23:49 ` Eric Biggers
2023-06-20 0:42 ` Luca Boccassi
2023-06-20 3:18 ` Eric Biggers
2023-06-20 5:45 ` Eric Biggers
2023-06-20 19:15 ` Luca Boccassi
2023-06-20 12:43 ` James Bottomley
2023-06-20 16:45 ` Eric Biggers
2023-06-20 19:34 ` Luca Boccassi [this message]
2023-06-20 16:55 ` Colin Walters
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMw=ZnQiu09jBsdbxxzyE3j98GqnmxxML+dwOQQs9kct1KZhWA@mail.gmail.com' \
--to=bluca@debian.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=alexl@redhat.com \
--cc=ebiggers@kernel.org \
--cc=fsverity@lists.linux.dev \
--cc=linux-doc@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=victorhsieh@google.com \
--cc=walters@verbum.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).