4:20 p.m.
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(a)fnal.gov> 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(a)lists.fedoraproject.org> 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(a)lists.fedoraproject.org> 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(a)lists.fedoraproject.org
> > > > To unsubscribe send an email to
> > epel-devel-leave(a)lists.fedoraproject.org
> > > > 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@lists.fedoraproj...
> > > > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> > >
> > _______________________________________________
> > epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to
epel-devel-leave(a)lists.fedoraproject.org
> > 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@lists.fedoraproj...
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> >