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. > > 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
