On Do, 09.12.21 23:55, Fedora Development ML (devel@xxxxxxxxxxxxxxxxxxxxxxx) wrote: > > 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 sounds strange to me. I mean, it's fine if new features initially only implement a subset of what they eventually are supposed to accomplish, but it appears to me you add only infrastructure without *any* use? Infrastructure that has no consuming feature typically doesn't work. Experience tells us that. Hence: I think it's fine if you don't go from 0 to 100 right away but there should be at least *some* benefit if you add such complex infra to the distro. > > 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. But that's an extremely weak property then? If I can have "ping" and "poweroff" binaries both signed by Fedora, but then swap them without the signing being able to detect that, why do this at all? > > 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. Uff. That might work in focussed deployments, but across a distribution like Fedora? Everytime there's an exploitable bug in *any* of the software Fedora ships you want to invalidate basically the *whole* distro? That sounds absolutely unmanagable and unrealistic to me. > 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? RPMs sign metadata. You can't trick RPM that easily into accepting "ping" as "poweroff" binary or vice versa. I mean, RPM's security model is from the 1990's, and it only does validation on request, not on access. So it's not great, but it *did* get right to authenticate a whole package in combination with all its metadata. And since versioned deps are part of that metadata you can express relationships. Still, this feature appears totally not throught to the end. I don't get the usecase? 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
