On Tue, Jan 5, 2021, at 3:19 PM, Florian Weimer wrote: > ... IMA seems to be pretty useless.
This is a complex and highly nuanced topic because IMA is both a mechanism and a set of potential *policies* that one can use, and a whole lot depends on the exact policy in use. Like SELinux in that it's a highly flexible thing; and related to that because IMA isn't the default in any mainstream distribution (that I can think of) it ends up being a "secondary" mechanism. There have definitely been multiple cases in the past where SELinux policy stops a chain of compromise - a great example is https://seclists.org/oss-sec/2019/q1/119 (The ostree read-only bind mount over /usr also stopped it, a great example of defense-in-depth) And one can definitely construct scenarios where an enforced IMA policy like `ima_tcb` would stop a similar chain - in the case of that runc flaw the attacker wouldn't have access to the signing key and so couldn't write a new binary that could be executed by root. But an ima_tcb policy would also e.g. break tooling like Ansible which is all about copying dynamic Python code from a remote host and executing it as root. And really that's a root problem in all security systems like this: it's just really hard to usefully distinguish between "code injected by a compromised privileged process" and "change the admin wants to make to their own computer". 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. 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. 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. A simple way to think of this is as a parallel with TPM-bound-LUKS (clevis) that we landed in Ignition - make it as easy as possible for admins to enable. Having pre-signed binaries isn't strictly necessary for that. The generalization of course of this is the model mentioned in the rpm-ostree issue where rather than doing signatures per-device you perform centralized image builds and seal /etc too, but as noted it's a rather large change in systems management (notable security benefits, breaks a lot of management tooling and greatly hampers one's ability to go in and test a change on a system). _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
