Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

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

 



On Thu, 2021-12-02 at 13:09 -0800, Kevin Fenzi wrote:
> On Thu, Dec 02, 2021 at 02:36:51PM -0500, Ben Cotton wrote:
> ...snip...
> > 
> > In the context of rpm, there are two parts to this:
> > * at build time, we compute the Merkle tree for the files within a
> > package, then sign it and ship it as part of the rpm metadata;
> 
> This is some kind of seperate signing that happens at build time?
> 
> Or it's added to the rpm metadata and covered by the normal package
> signing if/when the package is signed?

As part of the signing flow (e.g. via rpmsign), the Merkle tree is
generated and a signature is computed from it, which is then added to
the rpm metadata.

> > * at run time, if the fsverity rpm plugin is enabled, rpm will
> > install
> > the fsverity signature key and enable fsverity on files that are
> > installed.
> 
> Is this signature key the fedora rpm package signing key? 
> Or some seperate fsverity key?

fs-verity needs a RSA key/cert pair for file signing at package
signature time. At package install time, the cert needs to be loaded in
the appropriate kernel keyring. We've always used a dedicated keypair
during testing -- I'm not actually sure if the package signing key
could be reused for this, as it's a GPG key, but this is something we
should follow up on.

> > fs-verity works by using a Merkle tree to generate a checksum for
> > every data block in the system, and reads will fail if a single
> > data
> 
> every data block? or every packaged in rpms data block?

fs-verity only operates on files where it has been enabled via its
ioctl (which, if you install the RPM plugin, is taken care of by RPM on
your behalf). For those, fs-verity will checksum every data block
whenever it's accessed and validate it still matches.

> > block read fails it’s checksum. The signature of the the file is
> > validated against a public key loaded into the kernel keyring.
> > Because
> > fsverity operates on block reads, its runtime cost is small (as it
> > only needs to verify the block that is being accessed), and it can
> > protect from alterations at any point in time.
> 
> Is this via dm_verity kernel module? Or thats a completely seperate
> thing?

It's somewhat inspired by dm-verity, but it's a separate
implementation, the only shared logic is the hash computation code in
the kernel.

> > == Scope ==
> > 
> > * Proposal owners
> > ** btrfs kernel enablement work
> > ([
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=146054090b0859b28fc39015c7704ccc3c3a347f
> > landed in 5.15]); see this
> > [
> > https://developers.facebook.com/blog/post/2021/10/19/fs-verity-support-in-btrfs/
> > blog post] for more details
> 
> What does this mean for all the other filesystems? They would just be
> slower since btrfs is computing the trees as part of it's normal
> checksumming?

fs-verity requires support in the underlying filesystem. If you're
using a filesystem that doesn't support it and attempt to enable fs-
verity on a file, the ioctl will fail. Note that this is only a concern
at runtime, not at build time.

> > ** koji integration: koji will need to add the fs-verity metadata
> > to
> > packages when signing them
> 
> Well, koji doesn't sign packages. robosignatory listens for messages
> on
> the message bus for koji tagging and based on it's config, it asks
> sigul
> to sign rpms and import the signatures into koji. 
> 
> There's support in robosignatory to ask to sign files (used for the
> short lived IMA stuff), but I suspect it would need a new ability for
> this. 
> 
> Finally who is going to write this? Change owners?
> Or do you expect robosignatory maintainers to do so?

Thanks for clarifying! Yes, I think robosignatory is likely what we
want here. We (the Change owners) expect to do the work, though we'll
likely need some advice/help around code review, testing and
deployment.

> > * fs-verity requires filesystem support; currently support for ext4
> > and f2fs is already available; support for btrfs landed in 5.15
> 
> No xfs support?

Correct, XFS doesn't support fs-verity at the moment (though it could
be implemented if one wanted to).

Cheers
Davide
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux