Linux-FSCrypt Archive on
 help / color / Atom feed
From: Eric Biggers <>
To: Jes Sorensen <>
	Jes Sorensen <>
Subject: Re: [PATCH 0/7] Split fsverity-utils into a shared library
Date: Tue, 11 Feb 2020 15:14:54 -0800
Message-ID: <20200211231454.GB870@sol.localdomain> (raw)
In-Reply-To: <>

On Tue, Feb 11, 2020 at 05:09:22PM -0500, Jes Sorensen wrote:
> On 2/11/20 2:22 PM, Eric Biggers wrote:
> > Hi Jes,
> > 
> > On Mon, Feb 10, 2020 at 07:00:30PM -0500, Jes Sorensen wrote:
> >> From: Jes Sorensen <>
> >> If we can agree on the approach, then I am happy to deal with the full
> >> libtoolification etc.
> > 
> > Before we do all this work, can you take a step back and explain the use case so
> > that we can be sure it's really worthwhile?
> > 
> > fsverity_cmd_enable() and fsverity_cmd_measure() would just be trivial wrappers
> > around the FS_IOC_ENABLE_VERITY and FS_IOC_MEASURE_VERITY ioctls, so they don't
> > need a library.  [Aside: I'd suggest calling these fsverity_enable() and
> > fsverity_measure(), and leaving "cmd" for the command-line wrappers.] 
> > 
> > That leaves signing as the only real point of the library.  But do you actually
> > need to be able to *sign* the files via the rpm binary, or do you just need to
> > be able to install already-created signatures?  I.e., can the signatures instead
> > just be created with 'fsverity sign' when building the RPMs?
> So I basically want to be able to carry verity signatures in RPM as RPM
> internal data, similar to how it supports IMA signatures. I want to be
> able to install those without relying on post-install scripts and
> signature files being distributed as actual files that gets installed,
> just to have to remove them. This is how IMA support is integrated into
> RPM as well.
> Right now the RPM approach for signatures involves two steps, a build
> digest phase, and a sign the digest phase.
> The reason I included enable and measure was for completeness. I don't
> care wildly about those.

So the signing happens when the RPM is built, not when it's installed?  Are you
sure you actually need a library and not just 'fsverity sign' called from a
build script?

> > Separately, before you start building something around fs-verity's builtin
> > signature verification support, have you also considered adding support for
> > fs-verity to IMA?  I.e., using the fs-verity hashing mechanism with the IMA
> > signature mechanism.  The IMA maintainer has been expressed interested in that.
> > If rpm already supports IMA signatures, maybe that way would be a better fit?
> I looked at IMA and it is overly complex. It is not obvious to me how
> you would get around that without the full complexity of IMA? The beauty
> of fsverity's approach is the simplicity of relying on just the kernel
> keyring for validation of the signature. If you have explicit
> suggestions, I am certainly happy to look at it.

fs-verity's builtin signature verification feature is simple, but does it
actually do what you need?  Note that unlike IMA, it doesn't provide an
in-kernel policy about which files have to have signatures and which don't.
I.e., to get any authenticity guarantee, before using any files that are
supposed to be protected by fs-verity, userspace has to manually check whether
the fs-verity bit is actually set.  Is that part of your design?

- Eric

  reply index

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11  0:00 Jes Sorensen
2020-02-11  0:00 ` [PATCH 1/7] Build basic " Jes Sorensen
2020-02-11  0:00 ` [PATCH 2/7] Restructure fsverity_cmd_sign for shared libraries Jes Sorensen
2020-02-11  0:00 ` [PATCH 3/7] Make fsverity_cmd_measure() a library function Jes Sorensen
2020-02-11  0:00 ` [PATCH 4/7] Make fsverity_cmd_enable a library call() Jes Sorensen
2020-02-11  0:00 ` [PATCH 5/7] Rename commands.h to fsverity.h Jes Sorensen
2020-02-11  0:00 ` [PATCH 6/7] Move cmdline helper functions to fsverity.c Jes Sorensen
2020-02-11  0:00 ` [PATCH 7/7] cmd_sign: fsverity_cmd_sign() into two functions Jes Sorensen
2020-02-11 19:22 ` [PATCH 0/7] Split fsverity-utils into a shared library Eric Biggers
2020-02-11 22:09   ` Jes Sorensen
2020-02-11 23:14     ` Eric Biggers [this message]
2020-02-11 23:35       ` Jes Sorensen
2020-02-14 20:35         ` Eric Biggers
2020-02-19 23:49           ` Jes Sorensen
2020-07-30 17:52             ` Eric Biggers
2020-07-31 17:40               ` Jes Sorensen
2020-07-31 17:47                 ` Chris Mason
2020-07-31 19:14                   ` Eric Biggers

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200211231454.GB870@sol.localdomain \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-FSCrypt Archive on

Archives are clonable:
	git clone --mirror linux-fscrypt/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fscrypt linux-fscrypt/ \
	public-inbox-index linux-fscrypt

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone