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 <jsorensen@xxxxxx> > >> 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
|