apptainer 1.1.8-1 has an incompatible change for apptainer-suid users

[Dave Dykstra]

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

[Jonathan Wright]

Dave (Dykstra),

The process is pretty well laid out at
https://docs.fedoraproject.org/en-US/epel/epel-policy-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 <
[e-mail]> 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-f4...
> 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-f4...
> > 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 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[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/...
>
> 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-f4... 
> > 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-f4...
> > >
> > > 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 mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]...
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
> --
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat https://chat.almalinux.org/almalinux/messages/@jonathan
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[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/...
> >
> > 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-f4...
> > > 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-f4...
> > > >
> > > > 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 mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > 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/[e-mail]...
> > > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
> >
> > --
> > Jonathan Wright
> > AlmaLinux Foundation
> > Mattermost: chat https://chat.almalinux.org/almalinux/messages/@jonathan
> > _______________________________________________
> > epel-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]...
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Thanks everyone for the detailed information provided so far.  We
should evaluate each of these updates separately since the conditions
surrounding them are not the same across the board.

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

[Nick Howitt]

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/...
> > >
> > > 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-f4...
> > > > 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-f4...
> > > > >
> > > > > 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 mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > > > 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/[e-mail]...
> > > > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
> > >
> > > --
> > > Jonathan Wright
> > > AlmaLinux Foundation
> > > Mattermost: chat https://chat.almalinux.org/almalinux/messages/@jonathan
> > > _______________________________________________
> > > epel-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > 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/[e-mail]...
> > > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
> >
> > epel-devel mailing list -- [e-mail]
> > To unsubscribe send an email to 
> > [e-mail]
> > 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/[e-mail]...
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
>
> Thanks everyone for the detailed information provided so far.  We
> should evaluate each of these updates separately since the conditions
> surrounding them are not the same across the board.
>
> 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.

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

Same comment applies.
> 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

[Dave Dykstra]

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

[Dave Dykstra]

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

[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:
> 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.
> 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).
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Dave Dykstra]

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

[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:
> > > 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.
> > > 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).
> > > 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

[Carl George]

On Wed, Apr 26, 2023 at 11:31 AM 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/...
>
> 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.

Creating an issue there isn't strictly required, but it's typically
the mechanism we use to accomplish step 3, adding it to the agenda for
the next committee meeting.
> 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-f4...
> > 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-f4...
> > >
> > > 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 mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]...
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
> --
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Carl George]

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

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?
> 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.  I don't consider it a good idea, because if the
committee denies the update you have to do a revert commit and
possibly even add/increment an epoch to provide a correct upgrade path
to all users.  If you have a build you're not sure will be allowed in
EPEL, but you want to provide it quickly on an opt-in basis, I suggest
using copr instead.  If the update is approved you can increment the
release for the official EPEL build to have a clean upgrade path from
the copr build back to the EPEL build.
> 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.
> 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-f4...
> >
> > 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 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

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

[Dave Dykstra]

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

[Dave Dykstra]

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

[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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Dave Dykstra]

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

[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

[Dave Dykstra]

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 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]... 
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Dave Dykstra]

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 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]... 
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[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 <
[e-mail]> 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
> > > > > 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 -- [e-mail]
> > > To unsubscribe send an email to
>
> [e-mail]
> > > 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/[e-mail]...
> > > Do not reply to spam, report it:
>
> https://pagure.io/fedora-infrastructure/new_issue
> >
>
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Dave Dykstra]

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 <
> [e-mail]> 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
> > > > > > 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 -- [e-mail]
> > > > To unsubscribe send an email to
> >
> > [e-mail]
> > > > 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/[e-mail]...
> > > > Do not reply to spam, report it:
> >
> > https://pagure.io/fedora-infrastructure/new_issue
> > >
> >
> > epel-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]... 
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue

[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 https://copr.fedorainfracloud.org/ instead of EPEL.
Please inform the upstream maintainers of this.

Troy

On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  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
> > 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 <
> > [e-mail]> 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
> > > > > > > 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 -- [e-mail]
> > > > > To unsubscribe send an email to
> > >
> > > [e-mail]
> > > > > 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/[e-mail]...
> > > > > Do not reply to spam, report it:
> > >
> > > https://pagure.io/fedora-infrastructure/new_issue
> > > >
> > >
> > > epel-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to
>
> [e-mail]
> > > 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/[e-mail]...
> > > Do not reply to spam, report it:
> > > https://pagure.io/fedora-infrastructure/new_issue

[Dave Dykstra]

To Troy and the reset of the EPEL Steering Committee:

Thank you very much for granting the request.

The apptainer maintainers promise to do our best to avoid incompatible
updates in the future.  However if we discover another high severity
vulnerability in the setuid-root portion that cannot be worked around in
a compatible way, you will have put us into a very difficult position of
deciding between protecting the security of our users and making this
popular software more difficult for them to install.  It doesn't make
sense to me that packages should be punished for doing what they are
forced to do for good security.

Dave

On Wed, May 10, 2023 at 02:20:52PM -0700, Troy Dawson wrote:
> We discussed this in the weekly EPEL Steering Committee meeting. We broke
> this into two separate votes.
>
> *Allow the epel 7 update : Passed*
> Votes: All who voted, voted in favor of this.
> Notes: No notes.
>
> *Allow the epel 8 and 9 update - with a stern warning : Passed*
> Votes: 4 for, 2 against, 1 abstaining -
> Notes: Although your argument was that these needed the same breaking
> configurations to prevent future security issues, that wasn't what swayed
> the votes. The first reason was that having older versions in epel 8 and 9
> causes more problems. The second reason was that we felt we didn't give you
> a stern enough warning last time.
>
> *WARNING / ADVISEMENT / ATTENTION*
> This is the second time that apptainer has had breaking updates. The EPEL
> Steering Committee feels that if this happens again, then apptainer isn't a
> good fit for EPEL. We will pull apptainer from EPEL and recommend that you
> release it in COPR <https://copr.fedorainfracloud.org/ > instead of EPEL.
> Please inform the upstream maintainers of this.
>
> Troy
>
> On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  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
> > > 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 <
> > > [e-mail]> 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
> > > > > > > > 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 -- [e-mail]
> > > > > > To unsubscribe send an email to
> > > >
> > > > [e-mail]
> > > > > > 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/[e-mail]...
> > > > > > Do not reply to spam, report it:
> > > >
> > > > https://pagure.io/fedora-infrastructure/new_issue
> > > > >
> > > >
> > > > epel-devel mailing list -- [e-mail]
> > > > To unsubscribe send an email to
> >
> > [e-mail]
> > > > 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/[e-mail]...
> > > > Do not reply to spam, report it:
> > > > https://pagure.io/fedora-infrastructure/new_issue

[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 <https://copr.fedorainfracloud.org/ > instead of EPEL.
> > Please inform the upstream maintainers of this.
> >
> > Troy
> >
> > On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  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
> > > > 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 <
> > > > [e-mail]> 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
> > > > > > > > > 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 -- [e-mail]
> > > > > > > To unsubscribe send an email to
> > > > >
> > > > > [e-mail]
> > > > > > > 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/[e-mail]...
> > > > > > > Do not reply to spam, report it:
> > > > >
> > > > > https://pagure.io/fedora-infrastructure/new_issue
> > > > > >
> > > > >
> > > > > epel-devel mailing list -- [e-mail]
> > > > > To unsubscribe send an email to
> > >
> > > [e-mail]
> > > > > 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/[e-mail]...
> > > > > Do not reply to spam, report it:
> > > > > https://pagure.io/fedora-infrastructure/new_issue
>
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Dave Dykstra]

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 <https://copr.fedorainfracloud.org/  > instead of EPEL.
> > > Please inform the upstream maintainers of this.
> > >
> > > Troy
> > >
> > > On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  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
> > > > > 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 <
> > > > > [e-mail]> 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
> > > > > > > > > > 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 -- [e-mail]
> > > > > > > > To unsubscribe send an email to
> > > > > > [e-mail]
> > > > > > > > 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/[e-mail]...
> > > > > > > > Do not reply to spam, report it:
> > > > > > https://pagure.io/fedora-infrastructure/new_issue 
> > > > > > >
> > > > > > _______________________________________________
> > > > > > epel-devel mailing list -- [e-mail]
> > > > > > To unsubscribe send an email to
> > > >
> > > > [e-mail]
> > > > > > 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/[e-mail]...
> > > > > > Do not reply to spam, report it:
> > > > > > https://pagure.io/fedora-infrastructure/new_issue
> >
> > epel-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]... 
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
> -- 
> Carl George
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]... 
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Dave Dykstra]

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

Dave

On Thu, May 11, 2023 at 11:51:10AM -0500, Dave Dykstra wrote:
> To Troy and the rest of the EPEL Steering Committee:
>
> Thank you very much for granting the request.
>
> The apptainer maintainers promise to do our best to avoid incompatible
> updates in the future.  However if we discover another high severity
> vulnerability in the setuid-root portion that cannot be worked around in
> a compatible way, you will have put us into a very difficult position of
> deciding between protecting the security of our users and making this
> popular software more difficult for them to install.  It doesn't make
> sense to me that packages should be punished for doing what they are
> forced to do for good security.
>
> Dave
>
> On Wed, May 10, 2023 at 02:20:52PM -0700, Troy Dawson wrote:
> > We discussed this in the weekly EPEL Steering Committee meeting. We broke
> > this into two separate votes.
> >
> > *Allow the epel 7 update : Passed*
> > Votes: All who voted, voted in favor of this.
> > Notes: No notes.
> >
> > *Allow the epel 8 and 9 update - with a stern warning : Passed*
> > Votes: 4 for, 2 against, 1 abstaining -
> > Notes: Although your argument was that these needed the same breaking
> > configurations to prevent future security issues, that wasn't what swayed
> > the votes. The first reason was that having older versions in epel 8 and 9
> > causes more problems. The second reason was that we felt we didn't give you
> > a stern enough warning last time.
> >
> > *WARNING / ADVISEMENT / ATTENTION*
> > This is the second time that apptainer has had breaking updates. The EPEL
> > Steering Committee feels that if this happens again, then apptainer isn't a
> > good fit for EPEL. We will pull apptainer from EPEL and recommend that you
> > release it in COPR <https://copr.fedorainfracloud.org/ > instead of EPEL.
> > Please inform the upstream maintainers of this.
> >
> > Troy
> >
> > On Mon, May 8, 2023 at 7:29 AM Dave Dykstra  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
> > > > 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 <
> > > > [e-mail]> 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
> > > > > > > > > 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 -- [e-mail]
> > > > > > > To unsubscribe send an email to
> > > > >
> > > > > [e-mail]
> > > > > > > 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/[e-mail]...
> > > > > > > Do not reply to spam, report it:
> > > > >
> > > > > https://pagure.io/fedora-infrastructure/new_issue
> > > > > >
> > > > >
> > > > > epel-devel mailing list -- [e-mail]
> > > > > To unsubscribe send an email to
> > >
> > > [e-mail]
> > > > > 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/[e-mail]...
> > > > > Do not reply to spam, report it:
> > > > > https://pagure.io/fedora-infrastructure/new_issue