Messages in this thread | | | Date | Mon, 31 Jan 2022 14:29:19 -0500 | Subject | Re: [RFC][PATCH v3a 00/11] ima: support fs-verity digests and signatures (alternative) | From | Stefan Berger <> |
| |
On 1/31/22 10:12, Roberto Sassu wrote: >> From: Eric Biggers [mailto:ebiggers@kernel.org] >> 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@kernel.org] >>>> 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@linux.ibm.com/ >>>>>> 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@gmail.com >>>> >>>> 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.
FYI: An empty file signed with pkcs7 and an ecc key for NIST p256 generates a signature of size 817 bytes. If an RPM needs to carry such signatures on a per-file basis we are back to the size increase of nearly an RSA signature. I would say for packages this is probably too much size increase.. and this is what drove the implementation of ECC support.
| |