Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> * Peter Robinson:
> 
> 
> If the signatures end up in RPM headers, they will land in the RPM
> database, too.
> 
> “rpm -qla | wc -l” shows around 28,589 files for me, in the Fedora 33
> container image.  / seems to need 183 MiB right now.  If the signatures
> land in the RPM database and the file system, I expect at least 96 bytes
> per file signature (digests in the header are traditionally hex-encoded,
> I think).  That translates to 2.6 MiB, or ~1.4% size increase.
> 
> But quite likely there is some per-block overhead, so the numbers should
> be worse.
> 
> 

Hi,

I did some experimentation with the size differences of both the binary RPM packages and the RPMDB if the packages would contain IMA signatures.

I took all the packages in the Fedora base container image (registry.fedoraproject.org/fedora:latest), removed the Fedora signatures, and then got two copies of that: one with just GPG signed, one with IMA signatures and then GPG signed.

The size of the binary RPMs:
77412   ima-signed-pkgs
76632   rawpkgs
75660   signedpkgs

So on the binary RPMs, I am seeing a 2% increase.

After that, I created two containers, one where I reinstalled all the packages with the resigned versions and one where I reinstalled all the packages with the IMA resigned versions, and then looked at the RPMDB sizes:
Resigned: 14732   /var/lib/rpm
IMA + Resigned: 16332   /var/lib/rpm

So in the RPMDB, this comes down to a 11% increase.
However, to be noted here is that this is 15 or 16MB on a 584MB base image, so it's about a 0.3% increase of size compared to the base image itself.

Note that if you do not install the "rpm-plugin-ima", that is the only impact: RPM will only actually put the extended attributes in place once you install that package.

For more notes on how I got these results, see my notes at https://puiterwijk.fedorapeople.org/ima-size-research .


> The private key.  IMA is typically used for some form of remote
> attestation, I think.  I'm not sure if it is possible to distribute
> hardware with IMA enforcement.  And as long as enforcement can be turned
> of trivially (as required by the GPLv3, as far as I can tell), IMA seems
> to be pretty useless.

The default IMA policy in the kernel measures and attests nothing.
You would need to manually deploy an IMA policy with a line like "audit uid=0" for any file signature verification to be performed (in this case, on files opened as root).
After you have enabled policy lines like these, it's impossible to remove them without rebooting, but the system starts without a policy.
So you would need to manually deploy the policy, after which systemd loads it as one of the very first steps of the boot process and it takes effect.

Regards,
Patrick
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux