A new Polkit vulnerability
source link: https://lwn.net/Articles/882609/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
A new Polkit vulnerability
Posted Jan 26, 2022 16:51 UTC (Wed) by yodermk (guest, #3803) [Link]
A new Polkit vulnerability
Posted Jan 26, 2022 16:54 UTC (Wed) by zdzichu (subscriber, #17118) [Link]
A new Polkit vulnerability
Posted Jan 26, 2022 17:28 UTC (Wed) by dmoulding (subscriber, #95171) [Link]
I get that the processes are open. But I guess that by definition means this is a process that doesn't accommodate the idea of security vulnerability embargoes (which by definition cannot be handled "in the open"). Seems there could be a way to be open with everything, except embargoed fixes. I'd imagine that would be exactly along the lines of what the people who came up with this convention of embargoing security vulnerability disclosure had in mind.
A new Polkit vulnerability
Posted Jan 26, 2022 18:21 UTC (Wed) by mbunkus (subscriber, #87248) [Link]
1. The problem exists in pkexec, not Polkit in general.
2. This means that attackers must be able to execute arbitrary user-level programs in order to exploit the flaw.
3. Polkit is used mostly with desktop-style systems. Desktop-style systems are usually single-user, and that user has other ways of accessing root anyway.
4. Fedora is used much more widely as desktop systems than server systems, especially not as server systems where arbitrary users can upload arbitrary code to run (e.g. web site hosting with PHP).
Of course there are most likely huge Fedora-based machine farms in several organizations (universities maybe?) where arbitrary users do have unprivileged access that I'm simply not thinking about. Anyway, there's always "rm pkexec" as a temporary workaround.
A new Polkit vulnerability
Posted Jan 26, 2022 19:23 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link]
A new Polkit vulnerability
Posted Jan 26, 2022 19:36 UTC (Wed) by zdzichu (subscriber, #17118) [Link]
It was available the testing repository since yesterday.
The package was built at 25 Jan 2022 18:11:31 UTC (https://koji.fedoraproject.org/koji/buildinfo?buildID=190...).
The code changes landed in the repo yesterday at 17:51:47 UTC (https://src.fedoraproject.org/rpms/polkit/c/a55ef1ff5db9b...)
That's for nitpicking. As for your main point – yes, Fedora openness does not align with embargoes. Only way to prepare packages earlier would be to use some shadow build infrastructure, not widely visible. That would mean losing transparency, thus losing trust which is double important for security updates.
Actually, there is another way. Commits, builds, repo composes could get metadata tag like "notVisibleBefore" set to embargo lift timestamp. Before that time, it should only show changes to the owner. But this would require really intrusive surgery in many components (starting with git). It's unfeasible.
A new Polkit vulnerability
Posted Jan 26, 2022 20:05 UTC (Wed) by dmoulding (subscriber, #95171) [Link]
$ sudo dnf update polkit Fedora 35 - x86_64 37 kB/s | 13 kB 00:00 Fedora 35 openh264 (From Cisco) - x86_64 4.2 kB/s | 989 B 00:00 Fedora Modular 35 - x86_64 46 kB/s | 13 kB 00:00 Fedora 35 - x86_64 - Updates 35 kB/s | 10 kB 00:00 Fedora 35 - x86_64 - Updates 504 kB/s | 447 kB 00:00 Fedora Modular 35 - x86_64 - Updates 45 kB/s | 13 kB 00:00 Dependencies resolved. Nothing to do. Complete!
I just did that. So still no update available to me on this system. Not sure why if the patched build was available already.
But as to the feasibility, why is it infeasible to have closed infrastructure on which to make commits, do builds and test? Then when an embargo is lifted, the commits can be pushed to the public repo, builds done and released immediately, without having to wait for testing. Doesn't on the surface seem infeasible to me, but admittedly I'm not a developer for any distro (let alone Fedora) so I don't know what nuances would make this impractical.
A new Polkit vulnerability
Posted Jan 26, 2022 20:19 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
The patched builds are available in updates-testing repo. The commits go into a spec + patches repo in https://src.fedoraproject.org/ and then the builds happen via https://koji.fedoraproject.org/koji/
Once the builds are available there, Bodhi is used to push the updates to updates-testing for public comments and testing via https://bodhi.fedoraproject.org/
In this case, for Fedora 35, this is the errata
https://bodhi.fedoraproject.org/updates/FEDORA-2022-da040...
dnf install <foo> --enablerepo=updates-testing
> But as to the feasibility, why is it infeasible to have closed infrastructure on which to make commits, do builds and test?
It isn't infeasible but it is considerable amount of work to duplicate a good amount of the infrastructure somewhere privately, find the resources to test it privately and push it out slightly earlier while still allowing community volunteers to participate.
A new Polkit vulnerability
Posted Jan 26, 2022 22:29 UTC (Wed) by brunowolff (guest, #71160) [Link]
Composes of repos typically happens once a day with the set of packages in stable at around 0500 UTC. Typically the compose finishes 8 to 10 hours later and gets copied to the primary source for distribution. Before most people see the change, it needs to be copied to the mirror they use. I think some pick them up pretty quickly, but others might only check once a day.
If you happen to be using rawhide right now, composes have been failing more than usual the last week, including the last two days. If this threat is a high priority for you (e.g. if you have multiple users on your system that you don't fully trust to behave), then you need to pull a copy from koji or from this morning's failed compose (which will have a lot of updates).
A new Polkit vulnerability
Posted Jan 27, 2022 9:09 UTC (Thu) by nim-nim (subscriber, #34454) [Link]
Embargoes are predicated on the idea components are independant and you can prepare an update in a sekret top security facility isolated from everything else.
In reality modern components are deeply interdependant, moving one part echoes far and wide, and requires notifying lots of people (see: log4j).
A new Polkit vulnerability
Posted Jan 26, 2022 19:13 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link]
Distros with private infrastructure (e.g. RHEL) are able to prepare more easily.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK