To Troy and the reset of the EPEL Steering Committee: Thank you very much for granting the request. The apptainer maintainers promise to do our best to avoid incompatible updates in the future. However if we discover another high severity vulnerability in the setuid-root portion that cannot be worked around in a compatible way, you will have put us into a very difficult position of deciding between protecting the security of our users and making this popular software more difficult for them to install. It doesn't make sense to me that packages should be punished for doing what they are forced to do for good security. Dave On Wed, May 10, 2023 at 02:20:52PM -0700, Troy Dawson wrote: > We discussed this in the weekly EPEL Steering Committee meeting. We broke > this into two separate votes. > > *Allow the epel 7 update : Passed* > Votes: All who voted, voted in favor of this. > Notes: No notes. > > *Allow the epel 8 and 9 update - with a stern warning : Passed* > Votes: 4 for, 2 against, 1 abstaining - > Notes: Although your argument was that these needed the same breaking > configurations to prevent future security issues, that wasn't what swayed > the votes. The first reason was that having older versions in epel 8 and 9 > causes more problems. The second reason was that we felt we didn't give you > a stern enough warning last time. > > *WARNING / ADVISEMENT / ATTENTION* > This is the second time that apptainer has had breaking updates. The EPEL > Steering Committee feels that if this happens again, then apptainer isn't a > good fit for EPEL. We will pull apptainer from EPEL and recommend that you > release it in COPR <https://copr.fedorainfracloud.org/ > instead of EPEL. > Please inform the upstream maintainers of this. > > > Troy > > On Mon, May 8, 2023 at 7:29 AM Dave Dykstra <dwd@xxxxxxxx> wrote: > > > Hi Troy, > > > > If required, the epel8 & epel9 builds could have a patch added that > > changes the default of the new "allow setuid-mount extfs" to be "yes" > > instead of "no". That's all that would be required to disable the > > incompatible change. > > > > But as I said, I think it's a bad idea to make this behavior different > > on different OS versions. Epel8 & 9 are still vulnerable to the same > > general issue; even though they're likely to get patches for future low > > or moderate level severity vulnerabilities, they don't get patches > > quickly and so admins will have to turn this off for the period of time > > between announcement and patch upstream. Also the incompatibility is > > going to only affect a small percentage of epel8 & 9 users, and they > > should be able to quickly workaround it by adding the --userns option. > > > > The --userns option is already available everywhere. Are you > > suggesting that it default to --userns option behavior on epel8 & 9, at > > least for ext3, when "allow setuid-mount extfs = no"? I have thought > > of that but I believe that we cannot mix the setuid mode and the > > fuse2fs mount, at least not without a lot of major rework and careful > > investigation of the security implications. I don't think it would be > > good to automatically switch fully to the --userns mode with a setuid > > installation and "allow setuid-mount extfs = no", because then users > > will get subtle differences with other behavior depending on whether or > > not they are requesting something that is using an ext3 filesystem. > > > > Dave > > > > On Mon, May 08, 2023 at 06:47:04AM -0700, Troy Dawson wrote: > > > That makes it more clear for epel7. > > > But it will be strange for epel7 to have a higher version than epel8 and > > 9. > > > Would the apptainer maintainers be willing to create an update that has > > the > > > --userns option, as well as the original option? > > > Then for epel7 the rpm's would have the original option turned off, but > > for > > > epel8 and 9 the option could be there and update wouldn't be a breaking > > > update. > > > > > > That would allow users that have machines on RHEL 7,8 and 9 to use the > > same > > > version and secure options. > > > Users that only have machines on RHEL 8 and 9, would then have the option > > > to move to the more secure option when the time is good for them. > > > > > > Troy > > > > > > On Fri, May 5, 2023 at 3:30 PM Dave Dykstra via epel-devel < > > > epel-devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > The NVD analysis at > > > > https://nvd.nist.gov/vuln/detail/CVE-2023-30549 > > > > is now finished and they agreed with the impact score that I gave it. > > > > They ended up with an even higher rating because they said the attack > > > > complexity was low. I think the complexity is high, but in either > > case the > > > > overall severity is rated High. > > > > > > > > Dave > > > > > > > > On Thu, May 04, 2023 at 10:17:42AM -0500, Dave Dykstra wrote: > > > > > DT, > > > > > > > > > > I am not all arguing that CVE-2022-1184 impact score was incorrect. > > I > > > > can't imagine why you think that. > > > > > > > > > > By itself, CVE-2022-1184 is not a privilege escalation, because it > > can > > > > normally only be exploited by someone with write access to the > > filesystem > > > > boots, that is, root. Only with setuid-root apptainer/singularity > > does it > > > > become a privilege escalation. > > > > > > > > > > I have said that I think that CVE-2022-1184's "Privileges Required" > > was > > > > incorrect. It was you who suggested USB automounts being available to > > > > users may have been their reason for setting it to "low". If that's > > what > > > > they meant, then I think it makes perfect sense that they don't count > > that > > > > as a privilege escalation because physical access already gives > > privilege > > > > escalation in much easier ways. I said that that's probably why they > > only > > > > counted it as denial of service since that was the only thing new. > > > > > > > > > > Dave > > > > > > > > > > On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote: > > > > > > Dave, > > > > > > > > > > > > On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel > > wrote: > > > > > > > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote: > > > > > > > > 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: > > > > > > > ... > > > > > > > > > > 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. > > > > > > > > > > > > > > As DT pointed out, perhaps Red Hat was thinking that low > > privileges > > > > could > > > > > > > have been used by automounts of a USB device, but since that > > requires > > > > > > > physical access and there are much easier ways to get privilege > > > > escalation > > > > > > > with physical access, the only additional capability that would > > give > > > > to > > > > > > > a user is a crash, a denial of service. > > > > > > > > > > > > Impact scoring for a CVE doesn't depend on how it is triggered, > > > > though. If CVE-2022-1184 can provably give privilege escalation then it > > > > should be scored high on the impact > > > > (confidentiality/integrity/availability) metrics. It is not relevant > > to the > > > > impact whether I need physical access. The ease of the exploit is > > covered > > > > by the exploitability metrics, not the impact metrics. > > > > > > > > > > > > https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator > > > > > > > > > > > > My comment about automounts etc. was only related to why Red Hat > > might > > > > hve set the 'Privileges Required' property to low, even though `mount` > > is > > > > usually a root-only operation. Here you are arguing that CVE-2022-1184 > > was > > > > mis-scored on impact (confidentiality/integrity/availability). This is > > not > > > > related to my point about privileges required. > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > Now you seem to be missing the point of CVE-2023-30549. I agree > > that > > > > > > > there's no reason to believe that CVE-2022-1184 should have been > > > > marked > > > > > > > as higher impact than it was, but CVE-2023-30549 is about the > > extra > > > > > > > impact that setuid-root apptainer (prior to 1.1.8) gives to > > users. > > > > > > > It gives any user with a local account write access to the > > underlying > > > > > > > bits of a filesystem, and since the filesystem can be easily > > > > corrupted > > > > > > > by the user, and since CVE-2022-1184 is a memory corruption bug > > and > > > > not > > > > > > > a simple panic, it potentially allows privilege escalation. > > That's > > > > why > > > > > > > CVE-2023-30549 is high severity. > > > > > > > > > > > > Again, this is conflating scoring how difficult it is to exploit > > the > > > > vulnerability with its impact. > > > > > > > > > > > > The impact of a vulnerability is not greater if a vulnerability is > > > > easier to trigger. The impact portion of the score is about what > > happens if > > > > the vulnerability has been triggered. > > > > > > > > > > > > Your argument for the higher scoring of CVE-2023-30549 than > > > > CVE-2022-1184 is completely about the impact > > > > (confidentiality/integrity/availability) metrics. You are suggesting > > that > > > > CVE-2022-1184 was incorrectly scored, and that it has a privilege > > > > escalation impact, not just a denial of service impact. That claim has > > > > nothing to do with the privileges required, or Apptainer having a > > setuid > > > > component... which would be related to the exploitability metrics. > > > > > > > > > > > > If you believe it is true that CVE-2022-1184 allows privilege > > > > escalation, then you should argue that case against CVE-2022-1184, > > because > > > > the extfs issue should be graded as high severity through increased > > impact. > > > > If it was, then presumaby it'd be fixed in RHEL7 because of that. Then > > > > there would be no need for an incompatible change to Apptainer. > > > > > > > > > > > > DT > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ 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
