On Sun, 2024-03-31 at 13:03 +0200, Kevin Kofler via devel wrote: > > > 2. Our process for vetting packagers is, let's face it, from a security > > perspective almost *comically* patchy. There are 140 sponsors in the > > packager FAS group. Any one of those people - or someone who > > compromises any one of those 140 accounts - can grant any other person > > on earth Fedora packager status. Our policy on how they should do this > > is > > https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Sponsor_a_New_Contributor/#sponsoring_someone_for_fedora_package_collection > > . The words "trust" and "identity" do not appear in it. There is, > > AFAIK, no policy or procedure by which inactive sponsors have this > > power removed. There is no mandatory 2FA policy for sponsors. > > We already have a manpower problem, how is removing sponsors going to > improve the situation? Removing inactive sponsors makes it harder for an attacker to compromise an inactive sponsor's account and use it for evil. However, looking into it it looks like I made a mistake here: we do have an inactive *packager* policy, as well as an inactive *proven packager* policy. I had misremembered that we did not have the former, only the latter. So at *least* a sponsor who becomes completely inactive in the project will eventually get removed as a packager entirely (and hence also as a sponsor). I don't think that's entirely sufficient, but it's better than I thought. > > 3. We have no mechanism to flag when J. Random Packager adds > > "Supplements: glibc" to their random leaf node package. As a reminder, > > *we are a project that allows 1,601 minimally-vetted people to deliver > > arbitrary code executed as root on hundreds of thousands of systems*, > > and this mechanism allows any one of those people to cause the package > > they have complete control over to be automatically pulled in as a > > dependency on virtually every single one of those systems. > > This would get noticed pretty quickly, when that package comes up in update > transactions for no reason. I believe this has never happened so far. It is > just too obvious. "Would get noticed pretty quickly" is not really acceptable. It should not be possible to do it at all. This was just an example really, too. I am not a very good red teamer. I'm not imaginative enough. There are probably all sorts of more subtle ways a malicious person with packager privileges could leverage them to attack more people than they could attack just through 'normal' maintenance of a leaf package. Just for another example, we have had two significant cases recently of "package X incorrectly provides capability Y". 1. sdubby was providing grubby with a higher version than the real grubby package, which seems to have caused it to get installed in preference to grubby on fresh installs and upgrades when it should not have been. 2. some relatively obscure package somehow started including bundled copies of dozens of core system libraries, which made the auto-provides generator generate provides for those libraries. dnf then started preferring it over the 'real' providers of some of those libraries, I think because it had a shorter dep chain. Neither of these was, AFAICT, flagged as a potential security issue by anyone, but it seems reasonable to me that they should have been. I know about them because we happened to catch them as quality issues, but it is not hard to imagine that a malicious packager may be interested in using the same effect intentionally for evil, and they would obviously be careful to try and set things up such that this would *not* cause anything easily noticeable as a quality defect. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx https://www.happyassassin.net -- _______________________________________________ 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
