On Sat, 2022-02-12 at 14:52 +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Sat, Feb 12, 2022 at 12:50:58PM +0100, Vitaly Zaitsev via devel
wrote:
> > Thus, if you are able to create a build that
> > is submitted as an update (i.e. either build it for rawhide, or build it
> > for other releases and create a bodhi update), this is enough to wreak havoc
at
> > least on machines of people who use rawhide / updates-testing.
>
> If a hacker will "updates" the foo-bar package, it will only harm users
who
> have that package installed.
Yes, that is true. But a typical installation has between a few hundred and
a few thousand packages, and there are also users who purposefully install
additional packages e.g. for QA. So such a breach would have an important
impact, even if it wouldn't impact *all* packagers.
Also note that you can add Supplements:glibc and suddenly the package will
be installed in additional places.
Yup, we actually use this trick in openQA to get a package from an
additional repo installed without changing 'real' packages or comps. It
works.
> > As you certainly know, many updates don't receive any feedback, and almost
> > all updates receive no scrutiny if they install without errors.
>
> This is another problem. We should add some kind of gamification for QA
> testers, like achievements.
>
> > Thus a
> > nefarious update would have fairly high chances of going stable too.
> > I suppose that at some point it would be noticed, and the update pulled
> > and the account deactivated, but there is no automatic process for this.
>
> Maybe instead of deleting user accounts or their memberships, we should keep
> track of such updates and block auto-stable on karma and time for them?
We are not *deleting* user accounts, the proposal is to remove the
user from a group. We could do something more complicated, but that'd
require introducing special logic in multiple places (koji, bodhi,
probably others), and I don't see how it'd be better than the proposed
solution. If this alternative solution was implemented, for the user the
result would be equivalent to the proposed solution.
Replying to Vitaly here: the Bodhi process is absolutely not intended
to act as security review and I don't see that it really can. Someone
who goes as far as taking over a dormant maintainer account to submit a
nefarious package can almost certainly also arrange to have the update
immediately approved (note you can set the push threshold for a non-
critpath update to +1, so you need only one account to +1 it and it
will be pushed stable). Even ignoring that, security review is a
specialized skill and most of the people who review updates are not
trained in it. Even people who *can* do security review and also file
Bodhi feedback probably aren't doing a review of every update they +1,
because it's a time-consuming task and they are not being paid for it.
Bodhi functions as a quality sanity check. It's absolutely not security
review.
I think that while it's slightly unfortunate that this is the case, the
proposal is probably necessary, and I support it. Real world supply-
chain attacks are happening, regularly, and the Fedora package
collection is certainly a valid target for such an attack. We should do
what we can to make it more difficult to carry one out.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net