Re: [PATCH] fsverity: mark builtin signatures as deprecated

[Luca Boccassi <bluca@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 5104 bytes --]

On Thu, 2022-12-08 at 12:55 -0800, Eric Biggers wrote:
> On Thu, Dec 08, 2022 at 10:43:01AM +0000, Luca Boccassi wrote:
> > On Wed, 2022-12-07 at 19:35 -0800, Eric Biggers wrote:
> > > From: Eric Biggers <ebiggers@google.com>
> > > 
> > > fsverity builtin signatures, at least as currently implemented,
> > > are a
> > > mistake and should not be used.  They mix the authentication
> > > policy
> > > between the kernel and userspace, which is not a clean design and
> > > causes
> > > confusion.  For builtin signatures to actually provide any
> > > security
> > > benefit, userspace still has to enforce that specific files have
> > > fsverity enabled.  Since userspace needs to do this, a better
> > > design is
> > > to have that same userspace code do the signature check too.
> > > 
> > > That allows better signature formats and algorithms to be used,
> > > avoiding
> > > in-kernel parsing of the notoriously bad PKCS#7 format.  It is
> > > also
> > > needed anyway when different keys need to be trusted for
> > > different
> > > files, or when it's desired to use fsverity for integrity-only or
> > > auditing on some files and for authenticity on other files. 
> > > Basically,
> > > the builtin signatures don't work for any nontrivial use case.
> > > 
> > > (IMA appraisal is another alternative.  It goes in the opposite
> > > direction -- the full policy is moved into the kernel.)
> > > 
> > > For these reasons, the master branch of AOSP no longer uses
> > > builtin
> > > signatures.  It still uses fsverity for some files, but
> > > signatures are
> > > verified in userspace when needed.
> > > 
> > > None of the public uses of builtin signatures outside Android
> > > seem to
> > > have gotten going, either.  Support for builtin signatures was
> > > added to
> > > RPM.  However,
> > > https://fedoraproject.org/wiki/Changes/FsVerityRPM was
> > > subsequently rejected from Fedora and seems to have been
> > > abandoned.
> > > There is also https://github.com/ostreedev/ostree/pull/2269,
> > > which was
> > > never merged.  Neither proposal mentioned a plan to set
> > > fs.verity.require_signatures=1 and enforce that files have fs-
> > > verity
> > > enabled -- so, they would have had no security benefit on their
> > > own.
> > > 
> > > I'd be glad to hear about any other users of builtin signatures
> > > that may
> > > exist, and help with the details of what should be used instead.
> > > 
> > > Anyway, the feature can't simply be removed, due to the need to
> > > maintain
> > > backwards compatibility.  But let's at least make it clear that
> > > it's
> > > deprecated.  Update the documentation accordingly, and rename the
> > > kconfig option to CONFIG_FS_VERITY_DEPRECATED_BUILTINSIG.  Also
> > > remove
> > > the kconfig option from the s390 defconfigs, as it's unneeded
> > > there.
> > 
> > Hi,
> > 
> > Thanks for starting this discussion, it's an interesting topic.
> > 
> > At MSFT we use fsverity in production, with signatures enforced by
> > the
> > kernel (and policy enforced by the IPE LSM). It's just too easy to
> > fool
> > userspace with well-timed swaps and who knows what else. This is
> > not
> > any different from dm-verity from our POV, it complements it. I
> > very
> > much want the kernel to be in charge of verification and
> > validation, at
> > the time of use.
> 
> Well, IPE is not upstream, and it duplicates functionality that
> already exists
> upstream (IMA appraisal).  So from an upstream perspective it doesn't
> really
> matter currently.  That's interesting that you've already deployed
> IPE in
> production anyway.  To re-iterate my question at
> https://lore.kernel.org/r/YqKGcdM3t5gjqBpq@sol.localdomain which was
> ignored,
> can you elaborate on why IPE should exist when IMA appraisal already
> exists (and
> already supports fsverity), and why IPE uses the fsverity builtin
> signatures?

Yes, IPE has been in production for years, it used in the feature
described in the couple of minutes of Ignite starting at:
https://www.youtube.com/watch?v=PO5ijv6WDv0&t=608s

But I am not in the team that works on IPE, so I am not the best person
to answer the first question, I do not have a good enough understanding
of the implementation details of IPE/IMA to be able to say. I believe a
new revision will be submitted soon, the submitter is the right person
to ask that question.

The second question is easy: because the kernel is the right place for
our use case to do this verification and enforcement, exactly like dm-
verity does. Userspace is largely untrusted, or much lower trust
anyway.

> And are you sure that X.509 and PKCS#7 should be used in a new
> system?  These
> days, if you go through any sort of crypto or security review, you
> will be told
> not to use those formats since they are overly complex and prone to
> bugs.

Yes. We need to use the same mechanism as dm-verity, and in fact many
more systems, already make use of.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]