On Di, 12.01.21 12:20, Brian C. Lane (bcl@xxxxxxxxxx) wrote: > On Tue, Jan 05, 2021 at 01:05:01PM -0500, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents > > > > Note that this change was submitted after the deadline, but since it can be > > shipped in an complete state, I am still processing it for Fedora 34. > > > > > > == Summary == > > We want to add signatures to individual files that are part of shipped RPMs. > > These signatures will use the Linux IMA (Integrity Measurement > > Architecture) scheme, which means they can be used to enforce runtime > > policies to ensure execution of only trusted files. > > Who is going to use this feature? My guess is a very limited set of > users, so it seems unfair to dramatically increase the size of their > downloads and install footprint to support something they don't use. > Can't they be shipped on the side? An rpm of signatures that's > optionally installed would be more user friendly. > > Also, I (being unfamiliar with IMA), don't see how this is any better > than trusting the file hash signed by the fedora keys that we currently > have. So, my question would be similar to the above: what is the attack scenario you (as in feature submitters) want to address with this? I mean, this is a security mechanism afaiu, so you must have thought about an attack scenario. What is it? Can you elaborate on it? The feature page is irritatingly silent about it, but it's really what you should start with. Moreover, it appears that there was not much time spent in finding alternatives to what you want to do and figuring out if they wouldn't solve your problem better. Now, given that you never state the problem, I can only guess that what you want to attack is the problem of "offline security", i.e. you want that changes made offline to your file system are recognized on next boot? If offline security is what you are striving for, one would have expected that you list at least dm-verity and dm-integrity in your "Why not…?" section in the feature page. Now, my guess is that dm-verity is probably not interesting to you, since you want to keep RPM working, i.e. the immutability property of dm-verity is not a feature for you but a disqualifying problem. That however leaves dm-integrity (used with a HMAC hash function), so that local changes to the file systems can be made, but offline ones cannot – as long as the secret key for the HMAC function is known to the local system. Much like IMA dm-integrity/HMAC stuff exists already in the kernel too, so why IMA instead of such an approach? To me IMA appears quite a bogus concept tbh, and in particular deploying it without a policy that actually makes use of this sounds entirely pointless to me. Design your features to the end, implement them bit by bit — that would be an OK approach, but your appraoch appears to be, design one step without thinking ahead, in the vague hope it can be useful later? What I'd criticize about IMA is that it is inherently per-file. It's not clear to me what it does to protect the combination of files, or that even the metadata is properly secured too, for example the file system path used to find a file. i.e. if /usr/bin/true is fine to invoke, is /usr/foo/true too, if i copy the file there? And even more, if I copy the file to /usr/bin/false, is it still OK to execute then? If so, how is this stuff useful at all? what kind of offline, malicious changes do you intend to detect with this and refuse, and which kind of changes are you willing to accept? There's also the problem that Linux file system implementations are generally assumed not to be safe against rogue file system images, i.e. the kernel devs make clear that they do not give guarantees and do not systematically test their implementations against rogue file system images, and that those cannot exploit your kernel. Any security tech on top of a file system leaves the kernel vulnerable to that. (The dm-integrity+HMAC approach I outline above, does protect you against this btw). Also, what about TPM? It is my understanding that the IMA policy needs to be protected by TPM or such to be useful. Do you intend to work on that too? If not, what's the point? I could just change the IMA policy and you won't notice... Then, what about containers? They are kinda popular these days: if I untar them onto one of such systems, what happens to IMA? Is there any protection? Or is it hunting season for anyone? THen, when I tar up an image generated with these IMA xattrs, and untar them elsewhere, what happens? Do they still make sense there? What about performance? If I understand correct IMA calculates a hash some over the whole file and stores that away, is that correct? If you have a huge binary and you validate on start you thus have this huge latency first, to read the whole thing into memory and verify it? This sounds like it could be pretty awful, in particular on simpler, embedded machines. i.e. think firefox big binaries, or anything go or rust compiled where they prefer statically linking the whole world. (dm-verity + dm-integrity don't suffer by this: they have hashes in smaller data blocks, and thus only have to verify shorter blocks when they are actually accessed) To me, this appears be not thought to the end. This appears to be a project for its own sake, not because it would deliver anything truly useful. Hence, let me ask you: what is the attack scenario for this? Given that you do not intend to ship a policy by default, what are your next steps on all of this? Seriously puzzled about this feature, Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
