[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

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  instead of EPEL.
> > Please inform the upstream maintainers of this.
> > 
> > 
> > Troy
> > 
> > On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  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@lists.fedoraproject.org> wrote:
> > > >
> > > > > The NVD analysis at
> > > > > https://nvd.nist.gov/vuln/detail/CVE-2023-30549 
> 

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

Carl,

You don't seem to have looked at this closely enough to understand.
This is not an ordinary security problem that can be worked around in a
compatible way.  The security vulnerability is the feature itself.
There's nothing that can be done about it short of disabling the feature.

Of course if there was a compatible way to deal with this security
vulnerability, we would have done it.

Dave

On Thu, May 11, 2023 at 10:34:40PM -0500, Carl George wrote:
> Tens of thousands of upstream projects are packaged into Fedora and
> EPEL.  If they can find ways to deliver security fixes while following
> Fedora and EPEL update policies, then apptainer can too.  Asking you
> to follow these policies is not a punishment.  If you're unwilling to
> follow these policies, then I agree with Troy that copr will be a
> better fit for apptainer.
> 
> On Thu, May 11, 2023 at 11:51 AM Dave Dykstra via epel-devel
>  wrote:
> >
> > 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  instead of EPEL.
> > > Please inform the upstream maintainers of this.
> > >
> > >
> > > Troy
> > >
> > > On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  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 

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Carl George]

Tens of thousands of upstream projects are packaged into Fedora and
EPEL.  If they can find ways to deliver security fixes while following
Fedora and EPEL update policies, then apptainer can too.  Asking you
to follow these policies is not a punishment.  If you're unwilling to
follow these policies, then I agree with Troy that copr will be a
better fit for apptainer.

On Thu, May 11, 2023 at 11:51 AM Dave Dykstra via epel-devel
 wrote:
>
> 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  instead of EPEL.
> > Please inform the upstream maintainers of this.
> >
> >
> > Troy
> >
> > On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  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@lists.fedoraproject.org> wrote:
> > 

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

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  instead of EPEL.
> Please inform the upstream maintainers of this.
> 
> 
> Troy
> 
> On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  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@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.
> > 

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Troy Dawson]

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

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

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

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Troy Dawson]

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

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

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

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

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

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[David Trudgian]

On Wed, May 3, 2023, at 10:38 PM, Dave Dykstra via epel-devel wrote:
> On Wed, May 03, 2023 at 02:48:05PM -0500, Carl George wrote:
> > On Thu, Apr 27, 2023 at 9:42 AM Dave Dykstra via epel-devel
> >  wrote:
> > >
> > > We believe that it is important to apply this change to all EPEL releases,
> > > for these reasons:
> > > 1. The general vulnerability described in this CVE applies equally to all
> > > currently supported Linux distributions.  The Singularity/Apptainer
> > 
> > CVE-2023-30549 only applies to apptainer on RHEL 7 because the
> > underlying vulnerability (CVE-2022-1184) has been fixed on RHEL 8 and
> > 9.
> 
> CVE-2023-30549 most urgently applies to RHEL 7 because of the example
> of CVE-2022-1184, but as I explain in the rest of the point, it also
> applies in general to any similar moderate or low severity memory-
> corruption ext4 vulnerability that will come in the future on RHEL 8 & 
> RHEL 9 because Red Hat has no motivation to fix them urgently.

As in the other part of this thread, you are effectively arguing that the 
impact metrics of CVE-2022-1184 were incorrectly scored. You are additionally 
arguing that in future the impact metrics of filesystem CVEs are going to be 
scored incorrectly, such that privilege escalation vulnerabilities are scored 
as denial of service, hence have low / moderate severity, and are therefore not 
patched in a timely manner.

This is not something that can be fixed by an Apptainer CVE and incompatible 
change. If underlying filesystem CVEs are privilege escalations, but scored as 
denial of service... then that must be addressed for the benefit of everyone, 
not just Apptainer users.

There is a valid defence-in-depth strategy here, disabling kernel extfs mounts 
via apptainer-suid, that might be appropriate for a subset of users. It may or 
may not be appropriate as an EPEL incompatible change. But that's 
defence-in-depth in Apptainer, against a filesystem CVE... not a fix for an 
Apptainer CVE.

> > > community has long been aware that making setuid-root kernel
> > > filesystem mounts available to all users has been a risk, because
> > > https://lwn.net/Articles/652468/  briefly explained that kernel
> > > developers considered that to be a great risk.  System admins have
> > > been willing to live with the risk because (a) nobody had identified
> > > an attack, (b) the functionality was so useful, especially the
> > > squashfs mounts, and (c) there wasn't an alternative.  With the new
> > > information from the ext4 kernel filesystem owner, we now have more
> > > specifics on how the attack can be done including an example
> > > vulnerability, the ext3 mounts aren't as widely used as squashfs,
> > > and Apptainer has an alternative using unprivileged user namespaces.
> > > 2. RHEL8 & RHEL9 have unprivileged user namespaces enabled by default,
> > > so the functionality will still be available to most of the users.
> > > It does not automatically switch to the alternative, but there's a
> > > clear error message saying that it is disabled by configuration and
> > > suggesting that users add the --userns option (and of course if
> > > apptainer-suid is not installed it uses the user namespace mode
> > > automatically).
> > > 3. It is important to have consistency across platforms, since users and
> > > administrators often use more than one and it would be confusing to
> > > have different behavior on different platforms.  Admins can also
> > 
> > If consistency across platforms is important, then it seems prudent to
> > avoid this incompatible update across all three platforms, especially
> > this late in the RHEL 7 lifecycle.
> 
> It's not prudent to leave RHEL 7 exposed to high-severity vulnerabilities.
> Apptainer also supports more platforms than Red Hat.

RHEL 7 users are exposed to CVE-2022-1184, which is exploitable using 
Apptainer. Again, CVE-2022-1184 has not been scored high-severity. If you think 
it is a privilege escalation that should be addressed by arguing that there is 
a privilege escalation vuln in extfs... which would have high impact, and 
should be fixed in RHEL 7. Not by inferring an incompatible change to apptainer 
will wave that away.

DT
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[David Trudgian]

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
> >  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@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

On Wed, May 03, 2023 at 02:48:05PM -0500, Carl George wrote:
> On Thu, Apr 27, 2023 at 9:42 AM Dave Dykstra via epel-devel
>  wrote:
> >
> > We believe that it is important to apply this change to all EPEL releases,
> > for these reasons:
> > 1. The general vulnerability described in this CVE applies equally to all
> > currently supported Linux distributions.  The Singularity/Apptainer
> 
> CVE-2023-30549 only applies to apptainer on RHEL 7 because the
> underlying vulnerability (CVE-2022-1184) has been fixed on RHEL 8 and
> 9.

CVE-2023-30549 most urgently applies to RHEL 7 because of the example
of CVE-2022-1184, but as I explain in the rest of the point, it also
applies in general to any similar moderate or low severity memory-
corruption ext4 vulnerability that will come in the future on RHEL 8 & 
RHEL 9 because Red Hat has no motivation to fix them urgently.

> > community has long been aware that making setuid-root kernel
> > filesystem mounts available to all users has been a risk, because
> > https://lwn.net/Articles/652468/  briefly explained that kernel
> > developers considered that to be a great risk.  System admins have
> > been willing to live with the risk because (a) nobody had identified
> > an attack, (b) the functionality was so useful, especially the
> > squashfs mounts, and (c) there wasn't an alternative.  With the new
> > information from the ext4 kernel filesystem owner, we now have more
> > specifics on how the attack can be done including an example
> > vulnerability, the ext3 mounts aren't as widely used as squashfs,
> > and Apptainer has an alternative using unprivileged user namespaces.
> > 2. RHEL8 & RHEL9 have unprivileged user namespaces enabled by default,
> > so the functionality will still be available to most of the users.
> > It does not automatically switch to the alternative, but there's a
> > clear error message saying that it is disabled by configuration and
> > suggesting that users add the --userns option (and of course if
> > apptainer-suid is not installed it uses the user namespace mode
> > automatically).
> > 3. It is important to have consistency across platforms, since users and
> > administrators often use more than one and it would be confusing to
> > have different behavior on different platforms.  Admins can also
> 
> If consistency across platforms is important, then it seems prudent to
> avoid this incompatible update across all three platforms, especially
> this late in the RHEL 7 lifecycle.

It's not prudent to leave RHEL 7 exposed to high-severity vulnerabilities.
Apptainer also supports more platforms than Red Hat.

> > install the rpm on RHEL8 & 9 directly from github, and it would not
> > be good to have different behavior when installed from EPEL.

Dave
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

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

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

Dave
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Carl George]

On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel
 wrote:
>
> 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.

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

https://access.redhat.com/security/cve/CVE-2022-1184
https://nvd.nist.gov/vuln/detail/CVE-2022-1184
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

>
> > > 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@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



-- 
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Carl George]

On Thu, Apr 27, 2023 at 9:42 AM Dave Dykstra via epel-devel
 wrote:
>
> We believe that it is important to apply this change to all EPEL releases,
> for these reasons:
> 1. The general vulnerability described in this CVE applies equally to all
> currently supported Linux distributions.  The Singularity/Apptainer

CVE-2023-30549 only applies to apptainer on RHEL 7 because the
underlying vulnerability (CVE-2022-1184) has been fixed on RHEL 8 and
9.

> community has long been aware that making setuid-root kernel
> filesystem mounts available to all users has been a risk, because
> https://lwn.net/Articles/652468/ briefly explained that kernel
> developers considered that to be a great risk.  System admins have
> been willing to live with the risk because (a) nobody had identified
> an attack, (b) the functionality was so useful, especially the
> squashfs mounts, and (c) there wasn't an alternative.  With the new
> information from the ext4 kernel filesystem owner, we now have more
> specifics on how the attack can be done including an example
> vulnerability, the ext3 mounts aren't as widely used as squashfs,
> and Apptainer has an alternative using unprivileged user namespaces.
> 2. RHEL8 & RHEL9 have unprivileged user namespaces enabled by default,
> so the functionality will still be available to most of the users.
> It does not automatically switch to the alternative, but there's a
> clear error message saying that it is disabled by configuration and
> suggesting that users add the --userns option (and of course if
> apptainer-suid is not installed it uses the user namespace mode
> automatically).
> 3. It is important to have consistency across platforms, since users and
> administrators often use more than one and it would be confusing to
> have different behavior on different platforms.  Admins can also

If consistency across platforms is important, then it seems prudent to
avoid this incompatible update across all three platforms, especially
this late in the RHEL 7 lifecycle.

> install the rpm on RHEL8 & 9 directly from github, and it would not
> be good to have different behavior when installed from EPEL.
>
> Dave
>
>
> On Thu, Apr 27, 2023 at 02:42:13AM -0500, Carl George wrote:
> ...
> > EPEL 9:
> >
> > RHEL 9 has the fix for CVE-2022-1184.  CVE-2023-30549 requires
> > CVE-2022-1184 to be unpatched.  Because of this I'm opposed to an
> > incompatible update for apptainer in EPEL 9.  Apptainer in EPEL 9
> > should be modified to set the "allow setuid-mount extfs" option to yes
> > for compatibility, even if that isn't the upstream default.
> >
> > EPEL 8:
> >
> > RHEL 8 has the fix for CVE-2022-1184.  CVE-2023-30549 requires
> > CVE-2022-1184 to be unpatched.  Because of this I'm opposed to an
> > incompatible update for apptainer in EPEL 8.  Apptainer in EPEL 8
> > should be modified to set the "allow setuid-mount extfs" option to yes
> > for compatibility, even if that isn't the upstream default.
> >
> > EPEL 7:
> >
> > RHEL 7 appears to be vulnerable to CVE-2022-1184.  CVE-2023-30549
> > requires CVE-2022-1184 to be unpatched, so unlike EPEL 8 and EPEL 9 it
> > actually impacts the EPEL 7 apptainer package.  This CVE has not yet
> > been rated by NVD.  If the NVD assigns a rating of high (matching the
> > CNA suggestion) or critical, I would be agreeable to an incompatible
> > update of apptainer in EPEL 7.  If the NVD assigns a rating of medium
> > (matching CVE-2022-1184) or low, I would be opposed to an incompatible
> > update of apptainer in EPEL 7.
> >
> > https://nvd.nist.gov/vuln/detail/CVE-2023-30549
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



-- 
Carl George
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

On Thu, Apr 27, 2023 at 12:00:47PM +0100, David Trudgian wrote:
> On Thu, Apr 27, 2023, at 8:11 AM, 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?
> 
> My read of privileges required 'low' on CVE-2022-1184 is that perhaps
> it is related to the situation where, although a direct `mount`
> command against an extfs filesystem usually requires root, it is
> common that a non-root user can initiate mounts of extfs USB drives
> etc in 'standard' distro configurations via udisks2. I could be way
> off here, but at least on desktop systems there's usually a way for a
> non-root user to mount extfs removable drives.

It's possible that's what they meant, but as the already referenced
article https://lwn.net/Articles/652468/ makes clear, security experts
do not worry about that case because it requires physical access to 
the machine.  That's another type of privilege, and there are countless
ways for such a user to get root access.

> With respect to CVE-2023-30549 scoring, we're going to have quite a
> bit of confusion arising from the fact that the CNA suggested score at
> the NVD listing is different than on the GitHub GHSA page...
>
> On https://nvd.nist.gov/vuln/detail/CVE-2023-30549  the CNA provided
> vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H 
>
> This results in a higher score than CVE-2022-1184 because it lists
> 'Privileges Required: None'  which is surely incorrect, as you
> have to have a user account with enough privileges to run apptainer?

That's odd. It only makes a .1 diference in any case, and doesn't change
the high severity rating.

> On 
> https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
> the vector is CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
> 
> So... at the GHSA page, the Privleges Required is low (which seems
> correct), but compared to CVE-2022-1184:
> 
> 1) attack complexity is now high... which seems odd to change.

I think that was because they had a low complexity way to cause denial
of service.  It's high complexity to do privilege escalation.  The ext4
kernel developer was confident that a kernel security expert could cause
any use-after-free vulnerability into a privilege escalation, and that's
why I set this to be high complexity.

> 2) the suggested scoring has bumped Confidentiality and Integrity
> impact to 'high', where they are both 'none' in the underlying
> CVE-2022-1184. Not clear how this can be correct when CVE-2022-1184 is
> a denial of service vuln.

That's because of the potential privilege escalation.  I based the
individual property settings on CVE-2023-0386 which was a low complexity
privilege escalation.  Red Hat rated that high complexity, which I think
was another mistake because I was able to easily reproduce the exploit
on a pre-patched kernel.

> I'm quite confused looking at this now. I don't know how the GitHub
> submited CNA suggest score at the NVD would differ from the score on
> the GitHub Security Advisory. Was the scoring on the GHSA edited after
> publication, after it had been sent to the NVD?

Oh, you're on to something. I did change those settings after the
initial creation, after I learned about CVE-2023-0386, but it was before
publication.  I don't know how to get that corrected, but I will try.

> Also, I don't know what the justification is on the GHSA for bumping
> confidentiality / integrity impact, nor changing complexity from low
> -> high versus CVE-2022-1184.

Explained above.

Dave
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

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@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

On Thu, Apr 27, 2023 at 09:09:57AM +0100, Nick Howitt via epel-devel wrote:
> On 2023-04-27 08:42, Carl George wrote:
...
> > should be modified to set the "allow setuid-mount extfs" option to yes
> > for compatibility, even if that isn't the upstream default.
> 
> Can you not set the option to no for a new install and yes if it is an
> upgrade? You may need to be a bit cuter if it is upgraded again to see what
> it is upgrading from or read the old value first and don't update it.

Theoretically that's possible, but I don't think that's a good choice.
It would be a too subtle and surprising policy.  Also, you're right
that it would be especially tricky to distinguish a second upgrade.

Dave
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra via epel-devel]

We believe that it is important to apply this change to all EPEL releases,
for these reasons:
1. The general vulnerability described in this CVE applies equally to all
currently supported Linux distributions.  The Singularity/Apptainer
community has long been aware that making setuid-root kernel
filesystem mounts available to all users has been a risk, because
https://lwn.net/Articles/652468/ briefly explained that kernel
developers considered that to be a great risk.  System admins have
been willing to live with the risk because (a) nobody had identified
an attack, (b) the functionality was so useful, especially the
squashfs mounts, and (c) there wasn't an alternative.  With the new
information from the ext4 kernel filesystem owner, we now have more
specifics on how the attack can be done including an example
vulnerability, the ext3 mounts aren't as widely used as squashfs,
and Apptainer has an alternative using unprivileged user namespaces.
2. RHEL8 & RHEL9 have unprivileged user namespaces enabled by default,
so the functionality will still be available to most of the users.
It does not automatically switch to the alternative, but there's a
clear error message saying that it is disabled by configuration and
suggesting that users add the --userns option (and of course if
apptainer-suid is not installed it uses the user namespace mode
automatically).
3. It is important to have consistency across platforms, since users and
administrators often use more than one and it would be confusing to
have different behavior on different platforms.  Admins can also
install the rpm on RHEL8 & 9 directly from github, and it would not
be good to have different behavior when installed from EPEL.

Dave


On Thu, Apr 27, 2023 at 02:42:13AM -0500, Carl George wrote:
...
> EPEL 9:
> 
> RHEL 9 has the fix for CVE-2022-1184.  CVE-2023-30549 requires
> CVE-2022-1184 to be unpatched.  Because of this I'm opposed to an
> incompatible update for apptainer in EPEL 9.  Apptainer in EPEL 9
> should be modified to set the "allow setuid-mount extfs" option to yes
> for compatibility, even if that isn't the upstream default.
> 
> EPEL 8:
> 
> RHEL 8 has the fix for CVE-2022-1184.  CVE-2023-30549 requires
> CVE-2022-1184 to be unpatched.  Because of this I'm opposed to an
> incompatible update for apptainer in EPEL 8.  Apptainer in EPEL 8
> should be modified to set the "allow setuid-mount extfs" option to yes
> for compatibility, even if that isn't the upstream default.
> 
> EPEL 7:
> 
> RHEL 7 appears to be vulnerable to CVE-2022-1184.  CVE-2023-30549
> requires CVE-2022-1184 to be unpatched, so unlike EPEL 8 and EPEL 9 it
> actually impacts the EPEL 7 apptainer package.  This CVE has not yet
> been rated by NVD.  If the NVD assigns a rating of high (matching the
> CNA suggestion) or critical, I would be agreeable to an incompatible
> update of apptainer in EPEL 7.  If the NVD assigns a rating of medium
> (matching CVE-2022-1184) or low, I would be opposed to an incompatible
> update of apptainer in EPEL 7.
> 
> https://nvd.nist.gov/vuln/detail/CVE-2023-30549 
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[David Trudgian]

On Thu, Apr 27, 2023, at 8:11 AM, 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?

My read of privileges required 'low' on CVE-2022-1184 is that perhaps it is 
related to the situation where, although a direct `mount` command against an 
extfs filesystem usually requires root, it is common that a non-root user can 
initiate mounts of extfs USB drives etc in 'standard' distro configurations via 
udisks2. I could be way off here, but at least on desktop systems there's 
usually a way for a non-root user to mount extfs removable drives.

With respect to CVE-2023-30549 scoring, we're going to have quite a bit of 
confusion arising from the fact that the CNA suggested score at the NVD listing 
is different than on the GitHub GHSA page...

On https://nvd.nist.gov/vuln/detail/CVE-2023-30549 the CNA provided vector is 
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H 

This results in a higher score than CVE-2022-1184 because it lists 'Privileges 
Required: None'  which is surely incorrect, as you have to have a user 
account with enough privileges to run apptainer?

On 
https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg 
the vector is CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

So... at the GHSA page, the Privleges Required is low (which seems correct), 
but compared to CVE-2022-1184:

1) attack complexity is now high... which seems odd to change.

2) the suggested scoring has bumped Confidentiality and Integrity impact to 
'high', where they are both 'none' in the underlying CVE-2022-1184. Not clear 
how this can be correct when CVE-2022-1184 is a denial of service vuln.

I'm quite confused looking at this now. I don't know how the GitHub submited 
CNA suggest score at the NVD would differ from the score on the GitHub Security 
Advisory. Was the scoring on the GHSA edited after publication, after it had 
been sent to the NVD?

Also, I don't know what the justification is on the GHSA for bumping 
confidentiality / integrity impact, nor changing complexity from low -> high 
versus CVE-2022-1184.

I wonder if Dave Dykstra could clarify what's going on with the scoring 
differences with CVE-2022-1184, and between the NVD submsission and what's now 
seen at the GHSA link?

I guess it may not be an issue if any EL7 decision is just dependent on the 
NVD's own analysis and score, which will appear in due course.

Cheers,

DT


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Nick Howitt via epel-devel]

On 2023-04-27 08:42, Carl George wrote:
On Wed, Apr 26, 2023 at 12:54 PM David Trudgian  
wrote:


Dave, Jonathan,

Thank you for the replies and actions after my original message r.e. 
the incompatible upgrades policy.


I should now declare that I have an interest in how the discussion 
around the incompatible change for apptainer goes, due to being the 
packager and one of the upstream developers of singularity-ce... which 
is a fork from the same historic codebase as apptainer was.


WIth my upstream hat on... Sylabs, my employer, has a response to the 
publication of the Apptainer project's CVE-2023-30549 available here:


https://sylabs.io/2023/04/response-to-cve-2023-30549/

 which is likely broader than is relevant for EPEL packaging, but 
takes a basic position that CVE-2023-30549 is a duplicate of 
CVE-2022-1184 and is a medium severity DoS kernel vuln, and not a high 
severity security issue in apptainer / singularity-ce etc.


Trying to keep to what is likely of relevance for EPEL, CVE-2022-1184 
is a medium severity denial of service kernel vulnerability. It has a 
CVSS3.x base score of 5.5 - 
https://nvd.nist.gov/vuln/detail/CVE-2022-1184


The new CVE-2023-30549 opened by the Apptainer project against 
apptainer, and which the breaking change is aiming to address, depends 
on the presence of CVE-2022-1184, but has an (unreviewed) CVSS3.x base 
score of 7.1. I'm not clear how the Apptainer CVE bumps the score from 
5.5 to 7.1 for the same underlying vulnerability - 
https://nvd.nist.gov/vuln/detail/CVE-2023-30549


Red Hat seem to agree with the 5.5 score on CVE-2022-1184, and the 
kernel vuln has been patched in EL8 and EL9:


https://access.redhat.com/security/cve/cve-2022-1184

This means that in EPEL8 and EPEL9 the Apptainer vulnerability 
CVE-2023-30549 may be irrelevant. There is no direct impact due to the 
patches for CVE-2022-1184 that are in place, and the breaking change 
made to apptainer is, in my view, at least questionable. The argument 
about other possible but unproven kernel bugs doesn't seem to warrant 
duplicating the original CVE-2022-1184, raising its severity, and 
introducing a breaking change for EPEL8/9 users.


Admittedly, according to Dave Dykstra's findings, CVE-2022-1184 has 
not been patched in EL7. However, it's not clear to me that this 
justifies CVE-2023-30549, though a defense-in-depth strategy of 
disabling, or allowing users to disable use of extfs images in 
apptainer-suid on EL7 might be warranted. I'm not clear how EPEL 
packages are expected to handle (if at all) any "won't fix" security 
issues in components on which they depend.


FWIW, upstream in singularity-ce we are currently adding the ability 
for extfs image mounts through the kernel to be disabled, but not 
disabling them by default - as this is a breaking change to important 
functionality, and the underlying CVE-2022-1184 has been patched in 
most distros. We aren't considering this a security fix in 
singularty-ce, but the addition of a defence-in-depth option for users 
of distros with unpatched extfs vulnerabilities.


I'm hoping that the discussion / outcome w.r.t. apptainer will inform 
the approach for EPEL7 singularity-ce.


Many Thanks,

DT

On Wed, Apr 26, 2023, at 5:31 PM, Jonathan Wright via epel-devel 
wrote:

> Dave (Dykstra),
>
> The process is pretty well laid out at 
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
>
> I think leaving the package in epel-testing for now is OK but you definitely 
need to hold it from release repos until the policy is followed and the necessary 
approvals are obtained from the EPEL steering committee.
>
> I can't currently find it in the docs but I think going ahead and opening an 
issue at https://pagure.io/epel/issues will help facilitate the process.  I'm 
quite sure that this is/was documented somewhere when submitted an incompatible 
update for approval a few months back.  You can see it at 
https://pagure.io/epel/issue/212 which might help make more sense of the process 
as well.
>
> On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel 
 wrote:
>> DT is correct, this change is subject to the EPEL incompatible change
>> policy.  apptainer-suid-1.1.8 by default disables mounting of ext3
>> filesystems, because of CVE-2023-30549
>> 
https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
>> Most users don't use this feature, but a significant minority does.
>> Apptainer has a non-setuid alternative for the same functionality if
>> unprivileged user namespaces are available.
>>
>> 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
>> 

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Carl George]

On Wed, Apr 26, 2023 at 12:54 PM David Trudgian  wrote:
>
> Dave, Jonathan,
>
> Thank you for the replies and actions after my original message r.e. the 
> incompatible upgrades policy.
>
> I should now declare that I have an interest in how the discussion around the 
> incompatible change for apptainer goes, due to being the packager and one of 
> the upstream developers of singularity-ce... which is a fork from the same 
> historic codebase as apptainer was.
>
> WIth my upstream hat on... Sylabs, my employer, has a response to the 
> publication of the Apptainer project's CVE-2023-30549 available here:
>
> https://sylabs.io/2023/04/response-to-cve-2023-30549/
>
>  which is likely broader than is relevant for EPEL packaging, but takes a 
> basic position that CVE-2023-30549 is a duplicate of CVE-2022-1184 and is a 
> medium severity DoS kernel vuln, and not a high severity security issue in 
> apptainer / singularity-ce etc.
>
> Trying to keep to what is likely of relevance for EPEL, CVE-2022-1184 is a 
> medium severity denial of service kernel vulnerability. It has a CVSS3.x base 
> score of 5.5 - https://nvd.nist.gov/vuln/detail/CVE-2022-1184
>
> The new CVE-2023-30549 opened by the Apptainer project against apptainer, and 
> which the breaking change is aiming to address, depends on the presence of 
> CVE-2022-1184, but has an (unreviewed) CVSS3.x base score of 7.1. I'm not 
> clear how the Apptainer CVE bumps the score from 5.5 to 7.1 for the same 
> underlying vulnerability - https://nvd.nist.gov/vuln/detail/CVE-2023-30549
>
> Red Hat seem to agree with the 5.5 score on CVE-2022-1184, and the kernel 
> vuln has been patched in EL8 and EL9:
>
> https://access.redhat.com/security/cve/cve-2022-1184
>
> This means that in EPEL8 and EPEL9 the Apptainer vulnerability CVE-2023-30549 
> may be irrelevant. There is no direct impact due to the patches for 
> CVE-2022-1184 that are in place, and the breaking change made to apptainer 
> is, in my view, at least questionable. The argument about other possible but 
> unproven kernel bugs doesn't seem to warrant duplicating the original 
> CVE-2022-1184, raising its severity, and introducing a breaking change for 
> EPEL8/9 users.
>
> Admittedly, according to Dave Dykstra's findings, CVE-2022-1184 has not been 
> patched in EL7. However, it's not clear to me that this justifies 
> CVE-2023-30549, though a defense-in-depth strategy of disabling, or allowing 
> users to disable use of extfs images in apptainer-suid on EL7 might be 
> warranted. I'm not clear how EPEL packages are expected to handle (if at all) 
> any "won't fix" security issues in components on which they depend.
>
> FWIW, upstream in singularity-ce we are currently adding the ability for 
> extfs image mounts through the kernel to be disabled, but not disabling them 
> by default - as this is a breaking change to important functionality, and the 
> underlying CVE-2022-1184 has been patched in most distros. We aren't 
> considering this a security fix in singularty-ce, but the addition of a 
> defence-in-depth option for users of distros with unpatched extfs 
> vulnerabilities.
>
> I'm hoping that the discussion / outcome w.r.t. apptainer will inform the 
> approach for EPEL7 singularity-ce.
>
> Many Thanks,
>
> DT
>
> On Wed, Apr 26, 2023, at 5:31 PM, Jonathan Wright via epel-devel wrote:
> > Dave (Dykstra),
> >
> > The process is pretty well laid out at 
> > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> >
> > I think leaving the package in epel-testing for now is OK but you 
> > definitely need to hold it from release repos until the policy is followed 
> > and the necessary approvals are obtained from the EPEL steering committee.
> >
> > I can't currently find it in the docs but I think going ahead and opening 
> > an issue at https://pagure.io/epel/issues will help facilitate the process. 
> >  I'm quite sure that this is/was documented somewhere when submitted an 
> > incompatible update for approval a few months back.  You can see it at 
> > https://pagure.io/epel/issue/212 which might help make more sense of the 
> > process as well.
> >
> > On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel 
> >  wrote:
> >> DT is correct, this change is subject to the EPEL incompatible change
> >> policy.  apptainer-suid-1.1.8 by default disables mounting of ext3
> >> filesystems, because of CVE-2023-30549
> >> 
> >> https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
> >> Most users don't use this feature, but a significant minority does.
> >> Apptainer has a non-setuid alternative for the same functionality if
> >> unprivileged user namespaces are available.
> >>
> >> 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
> >> 

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[David Trudgian]

Dave, Jonathan,

Thank you for the replies and actions after my original message r.e. the 
incompatible upgrades policy.

I should now declare that I have an interest in how the discussion around the 
incompatible change for apptainer goes, due to being the packager and one of 
the upstream developers of singularity-ce... which is a fork from the same 
historic codebase as apptainer was.

WIth my upstream hat on... Sylabs, my employer, has a response to the 
publication of the Apptainer project's CVE-2023-30549 available here:

https://sylabs.io/2023/04/response-to-cve-2023-30549/

 which is likely broader than is relevant for EPEL packaging, but takes a 
basic position that CVE-2023-30549 is a duplicate of CVE-2022-1184 and is a 
medium severity DoS kernel vuln, and not a high severity security issue in 
apptainer / singularity-ce etc.

Trying to keep to what is likely of relevance for EPEL, CVE-2022-1184 is a 
medium severity denial of service kernel vulnerability. It has a CVSS3.x base 
score of 5.5 - https://nvd.nist.gov/vuln/detail/CVE-2022-1184

The new CVE-2023-30549 opened by the Apptainer project against apptainer, and 
which the breaking change is aiming to address, depends on the presence of 
CVE-2022-1184, but has an (unreviewed) CVSS3.x base score of 7.1. I'm not clear 
how the Apptainer CVE bumps the score from 5.5 to 7.1 for the same underlying 
vulnerability - https://nvd.nist.gov/vuln/detail/CVE-2023-30549

Red Hat seem to agree with the 5.5 score on CVE-2022-1184, and the kernel vuln 
has been patched in EL8 and EL9:

https://access.redhat.com/security/cve/cve-2022-1184

This means that in EPEL8 and EPEL9 the Apptainer vulnerability CVE-2023-30549 
may be irrelevant. There is no direct impact due to the patches for 
CVE-2022-1184 that are in place, and the breaking change made to apptainer is, 
in my view, at least questionable. The argument about other possible but 
unproven kernel bugs doesn't seem to warrant duplicating the original 
CVE-2022-1184, raising its severity, and introducing a breaking change for 
EPEL8/9 users.

Admittedly, according to Dave Dykstra's findings, CVE-2022-1184 has not been 
patched in EL7. However, it's not clear to me that this justifies 
CVE-2023-30549, though a defense-in-depth strategy of disabling, or allowing 
users to disable use of extfs images in apptainer-suid on EL7 might be 
warranted. I'm not clear how EPEL packages are expected to handle (if at all) 
any "won't fix" security issues in components on which they depend.

FWIW, upstream in singularity-ce we are currently adding the ability for extfs 
image mounts through the kernel to be disabled, but not disabling them by 
default - as this is a breaking change to important functionality, and the 
underlying CVE-2022-1184 has been patched in most distros. We aren't 
considering this a security fix in singularty-ce, but the addition of a 
defence-in-depth option for users of distros with unpatched extfs 
vulnerabilities.

I'm hoping that the discussion / outcome w.r.t. apptainer will inform the 
approach for EPEL7 singularity-ce.

Many Thanks,

DT

On Wed, Apr 26, 2023, at 5:31 PM, Jonathan Wright via epel-devel wrote:
> Dave (Dykstra),
> 
> The process is pretty well laid out at 
> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
> 
> I think leaving the package in epel-testing for now is OK but you definitely 
> need to hold it from release repos until the policy is followed and the 
> necessary approvals are obtained from the EPEL steering committee.
> 
> I can't currently find it in the docs but I think going ahead and opening an 
> issue at https://pagure.io/epel/issues will help facilitate the process.  I'm 
> quite sure that this is/was documented somewhere when submitted an 
> incompatible update for approval a few months back.  You can see it at 
> https://pagure.io/epel/issue/212 which might help make more sense of the 
> process as well.
> 
> On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel 
>  wrote:
>> DT is correct, this change is subject to the EPEL incompatible change
>> policy.  apptainer-suid-1.1.8 by default disables mounting of ext3
>> filesystems, because of CVE-2023-30549
>> 
>> https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
>>  
>> Most users don't use this feature, but a significant minority does.
>> Apptainer has a non-setuid alternative for the same functionality if
>> unprivileged user namespaces are available.
>> 
>> 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 

[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Jonathan Wright via epel-devel]

Dave (Dykstra),

The process is pretty well laid out at
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades

I think leaving the package in epel-testing for now is OK but you
definitely need to hold it from release repos until the policy is followed
and the necessary approvals are obtained from the EPEL steering committee.

I can't currently find it in the docs but I think going ahead and opening
an issue at https://pagure.io/epel/issues will help facilitate the
process.  I'm quite sure that this is/was documented somewhere when
submitted an incompatible update for approval a few months back.  You can
see it at https://pagure.io/epel/issue/212 which might help make more sense
of the process as well.

On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> DT is correct, this change is subject to the EPEL incompatible change
> policy.  apptainer-suid-1.1.8 by default disables mounting of ext3
> filesystems, because of CVE-2023-30549
>
> https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
> Most users don't use this feature, but a significant minority does.
> Apptainer has a non-setuid alternative for the same functionality if
> unprivileged user namespaces are available.
>
> 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.
>
> 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.
>
> 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.
>
> And another question: should I submit an epel ticket for this?  The
> policy doesn't mention that.
>
> Dave
>
> On Wed, Apr 26, 2023 at 09:41:16AM +0100, David Trudgian wrote:
> > Subject: Re: apptainer 1.1.8-1 appears to be an incompatible upgrade for
> apptainer-suid users
> >
> > Hello,
> >
> > The maintainer of the apptainer package has submitted updates to version
> 1.1.8-1 against epel-testing:
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-18a0e3fa23
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-44ff2475c4
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b31211e2ce
> >
> > I believe that the update should be considered an incompatible upgrade,
> requiring the incompatible upgrades policy to be followed, as it
> significantly changes behaviour for users who have the apptainer-setuid
> sub-package installed.
> >
> > The update now disallows, by default, workflows that involve ext format
> container images and overlays:
> >
> > ```
> > # Before update
> > $ apptainer exec sif-overlay.sif /bin/date
> > Wed Apr 26 09:12:37 BST 2023
> >
> > # Update to the testing package
> > $ sudo dnf update --enablerepo=epel-testing apptainer-suid
> >
> > # After update
> > $ apptainer exec sif-overlay.sif /bin/date
> > FATAL:   configuration disallows users from mounting SIF extfs partition
> in setuid mode, try --userns
> > ```
> >
> > I understand that the update is related to a security issue that
> upstream has published:
> >
> > CVE-2023-30549  -
> https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
> >
> > However, I don't think this exempts the update from the incompatible
> upgrades policy?
> >
> > I'd also like to note that CVE-2023-30549 is dependent on and
> potentially a duplicate of CVE-2022-1184, which has been patched in EL8 and
> EL9, but admittedly not in EL7.
> >
> > Thanks,
> >
> > DT
> >
> >
> ___
> epel-devel