> On Do, 02.12.21 14:36, Ben Cotton (bcotton(a)redhat.com) 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. > Good point, we were skimpy on that. In case you missed it, Davide just laid it out in his reply to the same question from Richard Jones higher in the thread. The short answer is that just this change as-is has no practical threat model, we viewed it as an enablement step that we believe has a realistic path to broadly authenticated rpm contents. Alternatively, it does give a sophisticated user an opportunity to build something like that for themselves as well. > 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? > If the file is still properly signed with a trusted matching certificate in the kernel keyring we can't/won't do anything about it. > 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? > I don't have a particularly specific answer to all of these questions, unfortunately. Perhaps someone with more knowledge about Fedora's existing key management can weigh in. But imagining we have the LSM hooks setup so that we never load anything executable without it being signed by a trusted key, then in my mind, banishing a bad shared library would require revoking the certificate. I think one could draw a reasonable parallel between package signing and file signing here, though. Users assemble meaningful system functionality out of a collection of packages, which are each individually signed. One of those packages could then be found to be compromised, and need to be removed, otherwise a user could download and install a perfectly valid signed package and have a bad time, which undermines the value of the signing. Is there something about composing executables out of files that is meaningfully different in this sense from composing systems out of packages? > 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
