As a followup: for additional justification of the importance of having this security change also in EPEL8 and EPEL9, please see the new addendum at the end of the security advisory https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg Dave On Thu, May 11, 2023 at 11:51:10AM -0500, Dave Dykstra wrote: > To Troy and the rest 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
