* Colin Walters:
I think the Change authors here trying to make it easier to enable IMA without the really awful hack of "boot up your installed system and run these shell scripts to sign", which is a laudable goal. Having pre-signed OS binaries would definitely help, but...in any kind of general case users are going to want to run code *not* from the distribution, so the tooling and docs need to generalize to user-owned keys.
That would also help to address the GPLv3 concern I have (which does not affect Fedora as a distribution, but could impact hardware vendors such as Lenovo).
Does IMA support multiple keys for one file system tree?
Also there's the inverse problem in that a lot of people will want to use IMA as a form of "application whitelisting" but there's...a lot of RPMs in Fedora. Less of a concern for RHEL at least.
Well, yes, but it will be very easy to get a file/path combination signed with the official Fedora key: Any packager will be able to obtain a properly signed /bin/bash that does something nefarious and will be accepted by any system that trusts the default Fedora IMA signing key.
I haven't checked whether the signatures actually cover the file path and file attributes. I guess hard links will be quite tough, but without path-based restrictions, it will be too easy to replace a production script with an signed insecure script that happens to reside under /usr/share/doc.
Anyways again I think a much more flexible user story is:
"As a Fedora IoT user I want to provide a key to use for IMA signatures of the operating system (rpm-ostree) (and potentially container images, etc.) and have the first-boot process handle IMA signing for me and automatically apply this across upgrades too."
The key would e.g. be stored in a TPM on device.
That's an interesting idea.
Given that the signature sizes are much worse than what I projected using minimum (256 bit security level) assumptions, infrastructure for creating the signatures on the target, without storing it in the RPM database, seems to be rather desirable.
Thanks, Florian