Linux-FSCrypt Archive on lore.kernel.org
 help / color / Atom feed
From: Jes Sorensen <jes.sorensen@gmail.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-fscrypt@vger.kernel.org, kernel-team@fb.com,
	Jes Sorensen <jsorensen@fb.com>
Subject: Re: [PATCH 0/7] Split fsverity-utils into a shared library
Date: Tue, 11 Feb 2020 17:09:22 -0500
Message-ID: <b49b4367-51e7-f62a-6209-b46a6880824b@gmail.com> (raw)
In-Reply-To: <20200211192209.GA870@sol.localdomain>

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 <jsorensen@fb.com>
>> 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.

> 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.

Thanks,
Jes

  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 [this message]
2020-02-11 23:14     ` Eric Biggers
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:
  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=b49b4367-51e7-f62a-6209-b46a6880824b@gmail.com \
    --to=jes.sorensen@gmail.com \
    --cc=ebiggers@kernel.org \
    --cc=jsorensen@fb.com \
    --cc=kernel-team@fb.com \
    --cc=linux-fscrypt@vger.kernel.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

Linux-FSCrypt Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fscrypt/0 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/ https://lore.kernel.org/linux-fscrypt \
		linux-fscrypt@vger.kernel.org
	public-inbox-index linux-fscrypt

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fscrypt


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git