linux-fscrypt.vger.kernel.org archive mirror
 help / color / mirror / 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 18:35:45 -0500	[thread overview]
Message-ID: <c39f57d5-c9a4-5fbb-3ce3-cd21e90ef921@gmail.com> (raw)
In-Reply-To: <20200211231454.GB870@sol.localdomain>

On 2/11/20 6:14 PM, Eric Biggers wrote:
> 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,
>> 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?

So the way RPM is handling these is to calculate the digest in one
place, and sign it in another. Basically the signing is a second step,
post build, using the rpmsign command. Shelling out is not a good fit
for this model.

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

Totally aware of this, and it fits the model I am looking at.

Jes

  reply	other threads:[~2020-02-11 23:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11  0:00 [PATCH 0/7] Split fsverity-utils into a shared library 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
2020-02-11 23:35       ` Jes Sorensen [this message]
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=c39f57d5-c9a4-5fbb-3ce3-cd21e90ef921@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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).