On Do, 02.12.21 14:36, Ben Cotton (bcotton@xxxxxxxxxx) wrote: Hmm, so what I am really missing on the feature page: what's the attack scenario here? Usually security features come with an attack scenario they are supposed to address. But there's no discussion about that. This protects file contents, not the metada, right? So what about the metadata? if I see a fs-verity enabled inode with libssl.so data in it today, and it's a vulnerably version, and I make a hardlink to it, and then it gets replaced by a fixed version (with a slightly updated name) — how you intend to make sure, that i can't fool you into loading my copy of the old file but under the new name? What about signing anyway? What is this precisely signed with? The keys for that when are they rolled over? Who manages those keys? The tea for that, who's doing that in Fedora? Is there any protection against downgrades between RPM package versions? Does this in any way protect combinations of binaries/libraries? I mean, pretty much all programs we ship consist of a large number of ELF objects, and you probably need to sign the combination of them, but this model doesn't look like it offers that at all? If a security bug is found in library X, how is it taken out of equation? What would the workflow for that look like on the Fedora side of things? The security model seems really strange to me I must say: so much infrastructure, and it doesn't protect at all how our programs are usually combined? Puzzled, Lennart _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
