* 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 -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill _______________________________________________ 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