On Sun, Mar 31, 2024 at 09:39:43AM -0700, Kevin Fenzi wrote: > On Sun, Mar 31, 2024 at 09:12:30AM -0700, Adam Williamson wrote: > > Thanks Arthur, yes, that was *exactly* the point. > > > > I would argue there's a danger of getting too tied up in very specific > > technical details of this attack. Yes, it's reasonable to think of ways > > to mitigate those specific mechanisms, at least at the appropriate > > levels (arguably, most of this is really directly an issue upstream of > > us). But it has been - for me - persuasively argued that the specific > > technical details were decided based on the wider goals of the attack. > > > > I buy the scenario where the starting point was "how can we poison the > > major distributions?" and everything from there derived from that > > starting point. xz was picked as the target because of all the specific > > technical stuff about systemd and ssh links which people are keen to > > dive deep into the details of, but *if that vector hadn't existed the > > attacker would just have chosen the next best one*. The specific form > > of the attack was then customized to the specific properties of xz, > > very cunningly - the whole thing about hiding the payload in binary > > test files. But if the attacker had chosen to attack a different > > project with different properties, they would have customized their > > attack to *that* environment with equal cunning, and it would probably > > look quite different. > > I think even stepping further back from the technical details is worth > considering. I think xz was picked because it had one maintainer who had > personal issues and low time/desire to continue work, and they were a > good target to be bullied into adding another maintainer. Are there > other critical packages we ship in similar situations? I can imagine the attacker had some sort of scoring system for projects: - No upstream patch review process (+10) - Complicated codebase (+20) - Small group of maintainers (+5) - Single, vulnerable maintainer (+50) - Linked to sshd (+1000) There's something to be said for us doing a similar sort of analysis. > > Worrying *only* about binary blobs in source repos or the specific > > details of how systemd opens compression libraries feels a bit narrow, > > to me - and especially so when we do it down at the distribution level > > where it's not necessarily primarily our responsibility, and I would > > argue is definitely not the *lowest* hanging fruit if we take a broader > > view of "what should we as a project be doing to raise the difficulty > > of supply chain attacks?" > > Agreed. I think theres lots of places we should improve, and focusing on > our own backyard first might be wise. But we can also work on the other > parts too! > > There are lots of things we _could_ do... we should discuss and consider > what ones make sense in what order. We should just do something because > we can. ;) > > Also, a reminder... nothing is ever 'secure'. security is a process. We > consider likelt threats, we try and mitigate them, and we keep doing it. > Things change and we should too. > > kevin Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
