On Thu, Dec 2, 2021, 5:33 PM Davide Cavalca via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
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.
IMA received significant pushback on the impact to RPMs and signing implications in Fedora. How does fs-verity compare here? Alternatively/additionally, why is fs-verity worth the hit for Fedora where IMA was not.
I'm not looking to create a false equivalence or compare apples to oranges, but I want to better understand why this is a more acceptable approach for Fedora.
As an aside, a few people have asked why RHEL didn't get IMA into Fedora first. Frankly, we tried and got feedback that it didn't apply to Fedora's needs and use cases. As of right now, we have no plans to force something into Fedora that the community doesn't want. If fs-verity is more acceptable or is described in a way that is better understood with enough similarities to IMA, we may try again.
> > * 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).
That means it would exclude Fedora Server and ELN as they are XFS based.
josh
_______________________________________________ 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
