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