On Mon, Jan 31, 2022 at 03:12:42PM +0000, Roberto Sassu wrote: > > From: Eric Biggers [mailto:ebiggers@xxxxxxxxxx] > > Sent: Friday, January 28, 2022 9:26 PM > > On Fri, Jan 28, 2022 at 09:05:01AM +0000, Roberto Sassu wrote: > > > > From: Eric Biggers [mailto:ebiggers@xxxxxxxxxx] > > > > Sent: Thursday, January 27, 2022 8:40 PM > > > > On Thu, Jan 27, 2022 at 11:35:12AM -0800, Eric Biggers wrote: > > > > > On Thu, Jan 27, 2022 at 07:46:09PM +0100, Roberto Sassu wrote: > > > > > > I wanted to propose a different approach for handling fsverity digests > > and > > > > > > signatures, compared to: > > > > > > > > > > > > https://lore.kernel.org/linux-integrity/20220126000658.138345-1- > > > > zohar@xxxxxxxxxxxxx/ > > > > > > > > > > > > In the original proposal, a new signature version has been introduced (v3) > > > > > > to allow the possibility of signing the digest of a more flexible data > > > > > > structure, ima_file_id, which could also include the fsverity file digest. > > > > > > > > > > > > While the new signature type would be sufficient to handle fsverity file > > > > > > digests, the problem is that its format would not be compatible with the > > > > > > signature format supported by the built-in verification module in fsverity. > > > > > > The rpm package manager already has an extension to include fsverity > > > > > > signatures, with the existing format, in the RPM header. > > > > > > > > > > > > Given that the fsverity signature is in the PKCS#7 format, IMA has already > > > > > > the capability of handling it with the existing code, more specifically the > > > > > > modsig code. It would be sufficient to provide to modsig the correct data > > > > > > to avoid introducing a new signature format. > > > > > > > > > > I think it would be best to get people moved off of the fs-verity built-in > > > > > signatures, rather than further extend the use of it. PKCS#7 is a pretty > > > > > terrible signature format. The IMA one is better, though it's unfortunate > > that > > > > > IMA still relies on X.509 for keys. > > > > > > > > Note, the only reason that support for fs-verity built-in signatures was added > > > > to RPM is that people didn't want to use IMA: > > > > https://lore.kernel.org/linux-fscrypt/b49b4367-51e7-f62a-6209- > > > > b46a6880824b@xxxxxxxxx > > > > > > > > If people are going to use IMA anyway, then there would be no point. > > > > > > Hi Eric > > > > > > I thought that the solution I came with could satisfy multiple needs. > > > > > > For people that don't want to use IMA, they could still continue > > > to use the existing signature format, and wait for an LSM that > > > satisfy their needs. They also have the option to migrate to the > > > new signature format you are defining. But will those people be > > > willing to switch to something IMA-specific? > > > > > > For people that use IMA, they could benefit from the effort > > > of people creating packages with the original fsverity signature. > > > > > > For people that are skeptical about IMA, they could be interested > > > in trying the full solution, which would probably be more easily > > > available if the efforts from both sides converge. > > > > > > If, as you say, you have concerns about the existing signature > > > format, wouldn't it be better that you address them from the > > > fsverity side, so that all users of fsverity can benefit from it? > > > > > > Currently, fsverity hashes the formatted digest whose format > > > is FSVerity<digest algo><digest size><digest>. Couldn't IMA > > > hash the same data as well? > > > > > > An idea could be to always sign the formatted digest, and have > > > a selector for the signature format: IMA, PKCS#7 or PGP. > > > > Adding support for the new IMA signature format to fsverity_verify_signature() > > *might* make sense. (When I added this code, my understanding was that it > > was > > just verifying signatures the way the kernel usually verifies signatures. I > > Ok. Do we need something more to sign other than the fsverity > formatted digest? If not, this could be the same for any method > we support. > > > don't think I realized there was a more direct, PKCS#7-less way to do it and > > that IMA used that way.) However, it would be better to use this as an > > opportunity to move people off of the built-in signatures entirely, either by > > switching to a full userspace solution or by switching to IMA. > > If what we sign remains the same, then we could support multiple > methods and use a selector to let fsverity_verify_signature() know > how it should verify the signature. I don't know what would be a > proper place for the selector. > > PKCS#7 seems ok, as it is used for kernel modules. IMA would be > also ok, as it can verify the signature more directly. I would also > be interested in supporting PGP, to avoid the requirement for > Linux distributions to manage a secondary key. I have a small > extension for rpmsign, that I would like to test in the Fedora > infrastructure. > > Both the PKCS#7 and the PGP methods don't require additional > support from outside, the functions verify_pkcs7_signature() > and verify_pgp_signature() (proposed, not yet in the upstream > kernel) would be sufficient. > > The IMA method instead would require the signature_v2_hdr > structure to be exported to user space, so that rpm could > produce a blob that can be interpreted by the kernel (this > work could also be done by evmctl). Also, IMA should pass > its .ima keyring to fsverity for signature verification, or should > simply get the signature and do the verification internally. > > Given that fsverity has already the capability of managing the > signature blob, it would make sense to still keep it. Adding it > in an xattr could be possible, but it would introduce more > constraints (requiring the filesystem to support xattrs). And, > an user of fsverity willing to use the IMA method would have > to look at security.ima. > > To summarize: I would prefer a method that relies on an > existing signature verification mechanism (PKCS#7) or that > has an equivalent API and simplify support for Linux distributions > (PGP). If we add the IMA method, available outside IMA, we > need to also add support for user space so that it can produces > the signature in the desired format, and preferably should use > the fsverity way of getting the signature. If the IMA method > would be used by IMA only, then IMA could store the signature > in its xattr and do the verification independently. > > Roberto > I think you are conflating the signatures themselves from where they are stored. The fs-verity built-in signatures feature could be extended to support the same signatures as IMA, while still storing the signature in the same way the fs-verity built-in signatures are currently stored (which doesn't use xattrs). But as I said, I don't think it makes sense to continue building on the fs-verity built-in signatures feature, as opposed to guiding users towards a full userspace solution or to IMA instead. - Eric
