On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel <epel-devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: > > On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel > ... > > > The summary of the CVE is that the way that apptainer & singularity > > > allow mounts of ext3 filesystems in setuid mode raises the severity of > > > many ext4 filesystem CVEs (ext3 filesystems are implemented by the ext4 > > > driver). OS vendors consider those CVEs to be low or moderate priority > > > because they assume that users do not have write access to the > > > underlying bits of the filesystem, but apptainer/singularity setuid mode > > > gives that access to users by default (before this release of apptainer). > > > Since vendors don't see urgency to patch low/moderate CVEs, it can take > > > a very long time for them to patch them and in fact RHEL7 is not patched > > > for one in particular. All this information came from a reliable source, > > > the owner of the ext4 kernel driver. > > > > The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as the > > NVD CVSS score. Both rate the "privileges required" property as low. > > From what I can tell that property would be rated high if they > > considered root privileges to be required. How does apptainer's use > > of setuid change anything here? > > According to the explanation I received from the ext4 kernel developer, > Red Hat's CVSS rating was incorrect on that property. Without singularity > or apptainer it does require high privileges to exploit. Red Hat's CVSS score breakdown for CVE-2022-1184 is: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H You're suggesting that Red Hat's rating should have been higher because they didn't factor in low privileges, but that is objectively false because they did score it with low privileges. If they had scored it for high privileges, that would have dropped the rating down from 5.5 to 4.4. There is no reason to believe that CVE-2022-1184 should have been marked as higher impact than it was, and thus I see no reason to justify the likely duplicate CVE-2023-30549 as high. https://access.redhat.com/security/cve/CVE-2022-1184 https://nvd.nist.gov/vuln/detail/CVE-2022-1184 https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator > > > > I am sorry to see that I have already done one step too many according > > > to the incompatible changes policy, and have made the release available > > > to epel-testing. However, I think it's important to make it available > > > that way for system administrators to install early. The large High > > > Energy Physics community that I represent has security teams that want > > > to be able to notify their site administrators to upgrade to respond to > > > this high severity CVE, and it would be so much better if the > > > announcement they send can say to install from epel-testing rather than > > > having to provide URLs to download from koji. > > > > You can't just ignore the policy because you feel it's important to > > make a particular update available quickly. If you feel the policy > > needs to allow for things to be done in that order, propose a change > > to the policy. > > The policy does already say parenthetically that a short-circuit is > needed for security updates. I will propose a change to make such a > short-circuit. > > > > So, to the EPEL Steering Committee members: must I unpublish this update > > > from testing, or may I leave it there and send an announcement to > > > epel-announce that it is there and pending approval by the committee? > > > The bodhi settings are set so they won't get auto-updated by karma or > > > time. > > > > We discussed this earlier today at the Steering Committee meeting. No > > one seemed to have an issue with allowing these updates to stay in the > > testing repo until we vote on it next week. Next time, follow the > > policy steps correctly. > > Thank you, I will do that. I apologize for starting off on the wrong > foot. I neglected to read the policy again in my focus on getting the > release done. > > Dave > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Carl George _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
